AIR sockets write data asynchronously—that is, the data you send to the socket goes into a buffer and the socket implementation decides when to actually write it out. Problem is, there is no way of knowing how much data has been written vs. how much is still in the buffer—no event to subscribe to, no bytesWritten property. There is a flush method on the socket, but it returns immediately without blocking so you can’t use this to force a synchronous write. (Since AIR doesn’t support multiple threads yet, writing synchronously isn’t really an option anyway.)

WTF Adobe? This is a glaring omission. Adrian raises an interesting question: did they actually do this on purpose? How hard could this possibly be?! I mean, they are simply exposing an underlying socket implementation provided by the OS, right? And every socket implementation on the block can tell you how much data is in the stupid buffer. grrrr.

Someone posted this as a bug on AIR’s issue tracker back in April. They didn’t get a response until August. Want to know what it said? “This is an enhancement request, i’ve logged it internally.” Sweet guys, thanks for the update.

Alas, it’s back to platform shopping for me. I hope Adobe can figure this out. Not only is it annoying, it makes them look downright stupid. Oh well.