if your server were written as an AIR application, it could connect to Stratus as just another peer, and Flash Players could then use the P2P NetStream API to connect to the AIR app via Stratus.
this would allow you to host your AIR service behind a NAT. however, data sent with NetStream.send() is sent with full reliability, so the benefits of UDP for (for example) timeliness would be lost for that use. there is currently no ActionScript API to take advantage of RTMFP's partial reliability capabilities for data transmission, which is what i suspect you want based on "real-time multiplayer game" and "take advantage of UDP". :)
Thanks for the reply Michael.
A flash/AIR app running on the server is exactly what I had in mind, though not behind NAT. However I am confused as to the purpose of stratus if send() is fully reliable. The service is advertised as being for real time communications like VOIP and video calling. Surely this would rely on lost or slow packets being discardable in favour of displaying the most recent data. Unless there is a planned AS3 API update then the scope of this project seems very narrow indeed.
in Flash Player 10, lost or slow Speex audio frames, when sent in "live, unbuffered" mode, can be discarded in favor of newer data. at the current time, no other data is sent using the partial reliability capability of RTMFP, including NetStream.send().
Oh well, TCP it is in that case. Even with that they don't allow you to disable the Nagle algorithm. Socket options like TCP_NODELAY and the inclusion of UDP are fairly trivial features to add which makes it all the more frustrating and puzzling as to why they haven't.
There's a feature request to enable unreliable UDP send which is absolutely required for real-time multipleplayer games with any number of players more than 2 (like 8, 16, or 32).
The trouble is you really really need unreliable UDP for real-time positional games where dropped packets will be recovered by future state diffs. It may be a more complex programming model to deal with unreliable UDP but still it should be available to developers, otherwise a LARGE class of real-time multiplayer games just aren't possible.
It sounds like Flash 10.1 will support unreliable data to be sent over RTMFP UDP.
source at 50:41 in the video: MAX 2009 - P2P on the Flash Platform with RTMFP
Partial Reliability Control at publishing peer
I'm not sure when Flash Player 10.1 beta will be out, but I'd really like to try it out and see how a real-time multiplayer game can work with unreliable UDP data.
data sent with NetStream.send() is sent with full reliability,so the packets are ordered and lossess ( NetStream would wait every packet'a ack and retranstmit it if need ?) , and ULP can't set the send buffer of NetStream . if lots of data would send ,if the send buffer( just like TCP window) would be very big.
the 10.1 would support partial reliability for data , just like udp datagram ?
Flash Player 10.1 will support partial reliability for NetStream.send(), but it is not just like UDP datagrams. all RTMFP data is subject to congestion control always. partial reliability (at this time) means no retransmission and limited transmit queue lifetime, so the data may expire even before the first transmission if the network is heavily congested or too slow. NetStream.send() messages are delivered to ActionScript at the receiver in the same order they were sent regardless of loss or network reordering.
the send buffer of NetStream is effectively infinite as far as bytes are concerned, but when partial reliability is selected, it is finite in time but still effectively infinite in bytes.
Are there available documents describing RTMFP "unreliable" protocol in detail and what the flow-control and guranteed order means to client/server latency (or P2P with a single peer acting as the server).
I'm curious what this means for "real-time" multiplayer games wanting to support low-latency efficient game state diffs, supporting 4 - 32 players in a single game (possibly with a dedicated server or one of the peers in the P2P group acting as the dedicated server authority like some XBox Live multiplayer games work).
I'm hoping to put together a simple benchmark app simulating multiple RTMFP clients with simulated internet latency and packetloss, and understand if it's possible to push the type of low-latency traffic that games like:
there are no documents available that describe RTMFP's partial reliability protocol in detail.
when using partial reliability mode, because of the in-order delivery of the data, there could be a delay in delivering data received after a loss on the order of one round-trip time or more, depending on whether other data is flowing.