tags:

views:

555

answers:

1

I'm writing a real-time app using a Flex/Flash client and my own server running on Linux.

I'd like to be able to send data from the Flex client in real time (in response to user actions). I've tried the following methods:

  • flash.net.NetConnection.call()
  • flash.net.sendToURL()
  • flash.net.Socket.write() followed by flash.net.Socket.flush()

In each case these calls always wait for the server to send an ACK before they can send data again. In other words, if you do:

var nc:NetConnection;
// Setup code left out
nc.call("foo", someData);
// Some more code left out
nc.call("foo", moreData);

The second nc.call() above won't send data to the server until the ACK for the first call has been recieved. I'd like to be able to send data immediately without waiting for that ACK.

If the round-trip time to the server is long (e.g. 300ms) I can only send data to the server 3 times a second. Ideally I'd like to be able to send data up to 30 times per second, but this is only possible with a RTT of around 30ms at the moment.

It doesn't matter if the server itself gets the data 300ms late - I realise I can't beat the speed of light.

Is there any way to get the Flash Player to send data without waiting for an ACK? In other environments this is done by setting the TCP_NODELAY flag on the socket but it seems I don't have that level of control in Flash/Flex.

Update: I think I may have stumbled on a workaround for this. I think the Flash Player tries to get the host browser to give it a separate TCP connection for each NetConnection object, subject to the connection limit for each browser, e.g. 2 for IE. The connection limit can be got around by using sub-domains (haven't tried this yet) so hopefully it should be possible to get closer to real-time behaviour by using a pool of NetConnections.

Thanks.

+1  A: 

Alternatively, you might have a look at something like Hemlock instead: http://hemlock-kills.com/

RickDT
Hemlock looks good. I haven't delved into the code yet, but I tried the drawing widget and used a packet sniffer to see that it was using XMPP. I presume it's using a Flash socket.It still suffers from the same problem I have, which is that it can't send overlapping packets: it has to wait for an ACK before sending the next packet. This seems to be a limitation of Flash.The drawing widget compensates by staggering the draw commands it receives rather than drawing them in one burst, which is clever.It would also be nice to stick to HTTP if possible, to get over firewalls/proxies.