AIR does. flash.net.DatagramSocket. You can always use a native extension to tap into the devices lower level socket functions.

Yes and you will also have a hell of a time getting any native extension to work in Flash CS5.5 as well. Flash Builder has built in ANE support but CS5.5 requires you to publish with the command line adt tool so you can use -extensionDir to compile the native extension. I haven't tried FDT but look that up, it is free and I think it is just a plugin for elipse.

I'm curious why you want to use a lossy protocol on a device that's bound to have enough issues staying connected while mobile as it is. I presume fast updates to a game.

Does flash.net.DatagramSocket not work for you on mobile?

Just look at the class I linked. It's AIRs UDP socket support. No need for a native extension if it works on mobile. I never tried it, I stick with tcp.

I only ever used it on desktop apps. There's plenty of working examples in the code linked above.

You're going to need a 'server' on each device running your app sniffing for a connection on a port to make any of this work. This isn't going to work outside wifi without a centralized solution. e.g. messages sent to a single central server and devices running the app get info pushed to them or request it from the server (not good if you need speedy netcode but fine for chat-esque apps).

I don't even think you need the ANE. If you look at the AIR DatagramSocket class I posted, as3 supports opening up a UDP socket. If and only if that doesn't work for you would you need an ANE.

You can use an ANE without a Mac, yes. I use the "Do not backup bit" ANE for iOS and it works fine. I code/publish on a PC.

Flash or HTML5 canvas would be perfectly suited to something like that. It has gobs of tools to draw dynamically. Take a look at the graphics class to see what's already built in. Google around a bit for chart and graph pre-made code as well. Sometimes you can find some prewritten code that's cheap and easy to use that would take you a lot longer to code yourself.

You're welcome

ANEs are extremely easy to use in Flash Builder. I use 4.6 and in your project properties there is a panel you can add ANEs to directly just as you add SWCs, etc. As you're setting up your project for the first time you even have a chance to specify ANEs during creating the project.

Oh, I thought you were asking if ANEs were supported in Flash Builder. I'm merely saying it has great built in support for ANEs. On that specific UDP ANE, I can't say if it works or not, I've never used it. Just that Flash Builder supports ANEs in general.

If you're using UDP you're clearly more interested in speed of updates rather than integrity of the transfer so I presume Apple (not adobe obviously) wants to cut down on people trying to do anything realtime with their device (gaming, etc).

This has been coming since before the smartphone. Service providers up to their same business model. Find the most premium feature, lure people in, cry about abuse and modify pricing models to rake in the cash. AT&T knew very well (since uh, home users have have unlimited internet for a decade before) that users will get used to using unlimited bandwidth. BTW, expect a non-unlimited home internet service pricing model, real soon. Now that people are hooked on using tons of bandwidth, welcome to the new long distance or the new roaming charge model.

Do you really think it costs more than a fraction of a penny to send an electron from inside the same state you're than across the country, if you own the wires? Large tel companies have only just now began debates about charging each other premiums for using each others networks. Before, they simply decided the +/- of each others usage wasn't worth as much as opening up communications was and no companies paid a single cent to send your phonecall across multiple companies lines.

They just charged you for it because you'd pay.

Welcome to your issue with UDP. You're trying to stream something game-esque that requires no integrity like a file transfer or you'd use the heftier TCP protocol.

With people now actually used to the idea of data caps after they successfully suckered people for years with unlimited, cried about network abuse (like they didn't forsee it) and removed the unlimited option, they're making sure it's not blindly easy to get a million calls the complaint department. As much as you want to recreate Crysis on a phone and let people play each other in realtime, they know the data usage is completely oblivious to the common user who plays on their (for now) unlimited home internet plan. They have no idea a couple hours of gaming can take a gigs worth of bandwidth, depending on the efficiency of the netcode.

They won't make it easy for you to use a persons bandwidth so the ISP gets nasty phonecalls because your app used their monthly bandwidth in 30 minutes. So it's of no suprise they're removing the ease of access to the protocol. And you should be very cautious to users of your app to explain how much bandwidth you require to use if you sense they are not on wifi. Otherwise expect nobody to use your app.

Adobe knows ANEs are the answer for almost all of these limits. As long as you're not trying to use a visual component an ANE will solve the issue. You can't port everything and ever expect to make money. AIR3.3 should come with the do not backup bit and a bunch more features as made mandatory. However I highly doubt you will see UDP.

Realtime gaming with inefficient netcode can consume as much bandwidth as video chat. Notice as soon as front facing cameras became available the ISPs immediately grandfathered the unlimited plans and slapped limits? That was planned. I bought the first phone in the USA to have a front facing camera, the HTC EVO 4G from Sprint. I saw where that was going, right away.

iOS devices do not show the user upfront permissions, only android devices do. When you load my iOS app I can easily consume 250mb in a very short time. I feel making socket usage a little tougher for game and video favored protocols who don't care about dropping packets was intentional. If you're smart enough to use an ANE, hopefully you're smart enough to both refrain from abusing the users data limits as well as warn the user about the data usage in a visible way. An options panel with bandwidth usage and/or a toggle to warn the user at a certain data usage would go a long way for games to keep users from rating you with 1 star and ranting about a $300 monthly bill.

Again, I feel Adobe did this deliberately. They did not completely block it, they just didn't make it easily abusable. Even though, well, it is. If it was completely intentional and demanded by the ISP/etc then you would see the ANEs unable to access those frameworks but they're clearly not blocked.

They haven't implemented every single thing so I'd wager to say the demand for UDP is pretty small.

I'm not trying to make it out to be a gigantic conspiracy. However as I said, money being king, eventually you need to come to a release. If I was behind on the development cycle some bean counter was warning me about and my job is on the line, I'd easily chalk as much up to ANEs as I could. UDP is a perfect example. Low overall desire for usage, especially in the mobile context, and implementable via an ANE.

HTTP traffic? Well, that better work or you're dead obviously.