I’m searching for a UDP socket solution!
Please help me to rank request 37686:
Just FYI UDP has some caveats on iOS (like not turning on the cellular or on demand VPN’s)
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/NetworkingTopics/Articles/UsingSocketsandSocketStreams.html
The recommended way to send and receive UDP packets is by combining the POSIX API and either the CFSocket or GCD APIs.
In iOS, POSIX networking is discouraged because it does not activate the cellular radio or on-demand VPN. Thus, as a general rule, you should separate the networking code from any common data processing functionality and rewrite the networking code using higher-level APIs.
Belongs WiFi to this cellular radio or do the talk about 3G/4G etc.
I need UDP to talk between iPad and some new firefight hardware I’m developing right now.
I’ve already tried this with TCP (on OSX) but the Ethernet IC’s in prototype world are very simple and will not perform good when they want to connect to other hardware a lot of times. UDP is the best option, they will not miss a single packet.
So, how will create (sell) a UDP for iOS8 declare plugin for me?
Xojo? Monkeybread? Or a new someone else?
My app will only run when it’s on the foreground!
It will run within perfect WiFi network.
I don’t care if UDP has issues when a app is is moved to the background as mentioned by Apple.
[quote=169816:@Jaap Cammeraat]Belongs WiFi to this cellular radio or do the talk about 3G/4G etc.
I need UDP to talk between iPad and some new firefight hardware I’m developing right now.
I’ve already tried this with TCP (on OSX) but the Ethernet IC’s in prototype world are very simple and will not perform good when they want to connect to other hardware a lot of times. UDP is the best option, they will not miss a single packet.[/quote]
UDP is NOT reliable - its meant to be fast but not make any guarantees about packet delivery, ordering etc
http://en.wikipedia.org/wiki/User_Datagram_Protocol
Dropping packets is just fine in UDP
TCP will retransmit packets until they are received and are in the correct order
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
Personally if it HAS to be reliable use TCP
I’ve done many tests with the version I already have on OS X.
TCP is very good I know and the Xojo serversocket is a real beauty.
But TCP connections are heavy for something like Arduino’s. Ethernet chips can have only 4 connections and have a lot of issues which I don’t like. After a lot of practice I’ve rebuild everything to UDP and none of the bits and bytes are dropped.
Ofcourse I have my own secure private WiFi network running my own hard- and software.
In short: it is reliable enough!
I have had lots of trouble with UDP over the years. It works and works great until it doesn’t. then it is a real PITA to troubleshoot.
this will always work well. but when released into the wild (public), you will not have 100% complete control of the network. Even if you are developing for your company internally. Because there will be others involved in part of the network (or all) and you can’t control it 100%.
I would expect this one line should imply “it needs to be fast AND reliable”
Ofcourse! But the dilemma is that iOS hasn’t a ServerSocket and cannot accept 5, 10, 50 clients to receive their ‘commands’.
The only way to switch again to TCP is using a Mac mini as a server so that anything from anywhere can connect to all other equipment. I’ve done this last year. I don’t want extra hardware with all it’s problems to maintain.
Simple controllers have simple ethernet ic’s and UDP is very simple and will work always.
Ofcourse you need a good, clean network.
I have a already a very clean network for my own equipment.
No other hardware is connected to it.
All packets are very very small and I never lost one of them.
But: I will switch to TCP if their is a good way to simulate a ServerSocket within iOS!
By the way, most controllers are connected with UTP.
Some, like an iPad, are connected over WiFi.
And: ServerSocket on iOS doesn’t solve my problems because the iPad is one of the clients of the controller-hardware. And this hardware cannot maintain a lot of open connections.
An alternative for me could be a serversocket-console app running on a cheap x86 board:
forum.xojo.com/20257-intel-galileo-gen-2
Well, technically we could of course develop an UDP Socket class.
But that would take time and cost money. A small PC is probably cheaper to monitor it.
What was the difficulty porting the TCP Socket object from the Desktop applications to this iOS environment?
[quote=170056:@Jaap Cammeraat]
But: I will switch to TCP if their is a good way to simulate a ServerSocket within iOS![/quote]
There’s no server socket on iOS
Well, desperate as I can be, I just ordered a minipc ( http://www.minidis.eu/DMPEB3332C4 ).
Small enough to give it a place in my controller’s Peli Case.
Big enough to play with ServerSocket/TCP and beyond.
Thanks for all help!
Thank you guys for pointing me another direction!
After 4 weeks my project is converted from UDP to TCP.
The most time consuming part was re-program the Atmel processors with my code.
And this week I prepared and running my server app on a new DIN PC 3332 with (for now) Windows Embedded 7/2009.
And today I’m finally creating the iPad part of it!
[quote=170356:@Jaap Cammeraat]Well, desperate as I can be, I just ordered a minipc ( http://www.minidis.eu/DMPEB3332C4 ).
Small enough to give it a place in my controller’s Peli Case.
Big enough to play with ServerSocket/TCP and beyond.[/quote]
Very cute little machine. Congratulations. These tiny PCs are very nice. The only drawback is that none seems to go beyond VGA, which is pretty limiting when most PCs routinely support at least 1280x800.
Michel, the DIN PC 3332 is VGA 1920x1080