socket.writeByte, socket.flush - atomic operations?

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:

Code:

---


        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.

Basically I'm worried about out-of-order data getting written to my socket. As long as each rpc gets written into the socket buffer in its entirety without interruption, I feel like this might work. If there's any chance it gets interrupted, then this is not a feasible approach.