Socket.writeByte, socket.flush - atomic operations?

Question

I've written a framework to facilitate RPC calls to a PHP server from  flash.  It's called flashmog.
I  have a bug that I'm trying to root out.  The way flashmog is set up is  that you can make a single socket connection to a server and flashmog  will multiplex different RPC calls over that single socket using a very  simple protocol.  Basically every RPC call gets serialized into a byte  array and then crammed onto the socket, preceded by an UnsignedInt which  indicates how long the serialized RPC is.  This is handled by a method  I've written in a class that extends the flash.net.Socket class:
         public function executeRPC(serviceName:String, methodName:String,  methodParams:Array):void {
             if (!this.connected) {
                 log.write('RPCSocket.executeRPC failed. ' + methodName +  ' attempted on service ' + serviceName + ' while not connected',  Log.HIGH);
                 throw new Error('RPCSocket.executeRPC failed. ' +  methodName + ' attempted on service ' + serviceName + ' while not  connected.');
                 return;
             var rpc:Array = new Array();
             rpc[0] = serviceName;
             rpc[1] = methodName;
             rpc[2] = methodParams;
             var serializedRPC:ByteArray = serialize(rpc);
             if (!serializedRPC) {
                 log.write('RPCSocket.executeRPC failed.  Serialization  failed for method ' + methodName + ' on service ' + serviceName,  Log.HIGH);
                 dispatchEvent(new IOErrorEvent(IOErrorEvent.IO_ERROR,  false, false, 'RPCSocket.executeRPC failed.  Serialization failed for  method ' + methodName + ' on service ' + serviceName));
             super.writeUnsignedInt(serializedRPC.length); // send a  message length value
             super.writeBytes(serializedRPC);
             super.flush();
         } // executeRPC
This works fine  for small messages and low-bandwidth situations, but when I start  cramming large amounts of data down the socket (say 180,000 bytes per  second) then things get out of whack and the server starts complaining  about unreasonable message length values.  The message length value is  transmitted as the first few bytes of an rpc call (see the  writeUnsignedInt call above) and indicates how long the upcoming RPC  call is in bytes.
It seems that the server is trying to  interpret parts of my rpc data as a message length indicator.  This  means the sync is off.
Question 1: Is there anyway  flash would interrupt the execution of the code in this function such  that part of  a separate RPC call might be transmitted in the middle of a  prior rpc call?  Or is this code atomic?  Can I reasonably depend on  flash to load my data into the socket in the order that I call it?
Question  2: Can anyone recommend a better approach to sending these rpc calls?   Ideally something that would be able to synchronize itself continously  rather than depending on in-order transmission of data I cram onto the  socket.

Answer 1

This test was pretty carefully designed. The packets being sent are all about 1000 or 2000 bytes.  The max size for a packet is much much larger (500 Kbytes) and the error I'm getting is complaining about a message length of 959,459,634 which is impossible.
It has occurred to me to try and packet-ize my rpc calls but that's a lot of extra effort.  I was rather hoping to rely on the code to pour data into the socket in order and retrieve it in order.  This is supposed to be guaranteed by the type of socket in use.