udp in flash

This is a memo to myself more than anything else… but there has got to be a way to use UDP from a SWF running through your web browser.

Pieces of the puzzle:

  • Flash 9 has binary TCP socket support, but no UDP.
  • Standalone projectors like MDM Zinc can add UDP capabilities to the mix.
  • A projector and a SWF in the browser can communicate together very happily via the LocalConnection interface.

But web browsers are understandably reluctant to download and run a 3rd party UDP proxy application for you 😉 It’s also not terribly platform independent to require something running in userspace outside of the VM.

Java has UDP support. You could write a UDP proxy in Java that uses a standard local TCP socket to talk to the SWF – both the SWF and the applet would have to load from the same page. Don’t know whether Java’s and Flash’s security policies would allow this sort of behavior… probably not. I know applets have difficulties connecting to anything but the originating server – so they probably can’t listen for traffic on the local host either. And if they can, there’s probably some big security certificate you have to sign in blood and offer to the Sun gods or something…

Of course, the dumb option would be to have a remote TCP->UDP proxy… but that eliminates any sort of performance gain that might have been achieved by using UDP in the first place, so that’s only valid in the weird case where you honestly need to talk to a UDP server for whatever reason and don’t care about the lag.

No, the proxy must run locally, somehow.

4 thoughts on “udp in flash”

  1. hrmf.
    I want to use an UDP server, and have run into the same set of problems.. and came up with many of the same not so great solutions.

    The zinc solution you have there might be the best… but ich.

    Resigning I am thinking for speed over tcp you could open multiple tcps and use them asyncronously? do you know if that would work?


  2. Asynchronous TCP sockets could probably give at least different performance than a single one – but I don’t know if that difference would be measurable.

    Part of the bottleneck is probably just how TCP stacks are implemented. Most machines don’t send your packet out quite instantly, they let it sit in a buffer first. Add TCP’s error control elements on top of things, and you’ve got a lot of potential for minute delays in excess of what it actually takes to send the data between client and server.

    Opening multiple sockets might give some sort of strange performance increase, but it also complicates things a great deal and ties up more system resources. Plus, there’s always the chance that going to all of that extra effort provides no real performance gain at all, since the packets quite possibly just sit in the same TCP buffers.

    Also wrt using Zinc for the proxy… it’s not even as good as it sounds initially. To get any decent coverage, you’d have to buy what amounts to essentially two separate licenses if you want to compile projectors for both Windows and OSX. There is no Linux option, and heaven forbid you wanted to run something like that on an embedded system 😉

  3. With a signed (even self-signed) java applet, you can get full privileges to do whatever you want, including opening a socket to anywhere, but means your user has to accept this.

    You can communicate with both java applets and flash with javascript, you could maybe use this as the communication bridge.

    Looks like there’s be UDP in Flash 10 anyway though.

Leave a Reply

Your email address will not be published. Required fields are marked *