UDP and TCP connections on different iOS Versions

[Nahshon Williams]

This is what I have seen so far . . .

Also on Pastie (in case Google scrambles this up)
http://www.pastie.org/2053056

Multitasking disabled on all iPads.
Only one app on one ipad enabled at any time of testing.
Using Gui Designer 2.3.4.2
Hercules Command: r1call_ack=1$0D
Regex: r1call_ack=(1)\x0D
There is a timer command sent at the push of a button.


iOS 4.3.3 Using UDP Maintain connection. 255.255.255.255 port 4996

iViewer stable 3.4.2 build 124 Connection:
Connection join: goes HIGH
On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.

iViewer Next 4.0.2 build 154:
Connection join: Stays LOW
On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.



iOS 4.3.3 Using TCP Maintain connection. Computer IP defined in system properties (to communicate with hercules TCP server)

iViewer stable 3.4.2 build 124:
Connection join: goes High
Hercules TCP server shows active connection.
On Match regex Response to Hercules Command: TRIGGERS commands as expected.
Timer Commands: TRIGGER and display in the "received data" window in Hercules.
All is well ;-)

iViewer Next 4.0.2 build 154:
Connection join: Stays LOW
Hercules TCP server does not show any connection attempts.
On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
Timer commands: DO NOT TRIGGER and display in the "recieved data" window in Hercules.






iOS 4.2.1 Using UDP Maintain connection. 255.255.255.255 port 4996

iViewer stable 3.4.2 build 124:
Connection join: goes High
Hercules TCP server shows active connection.
On Match regex Response to Hercules Command: TRIGGERS commands as expected.
Timer Commands: TRIGGER and display in the "received data" window in Hercules.
All is well ;-)

iViewer Next testflight 4.0.3 build 157:
Connection join: Stays LOW
On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
Point of interest: The timer commands Display (after resetting connection in Hercules)
Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.



iOS 4.2.1 Using TCP Maintain connection. Computer IP defined in system properties (to communicate with hercules TCP server)

iViewer stable 3.4.2 build 124 Connection:
Connection join: goes High
Hercules TCP server shows active connection.
On Match regex Response to Hercules Command: TRIGGERS commands as expected.
Timer Commands TRIGGER and display in the "received data" window in Hercules.


iViewer Next testflight 4.0.3 build 157:
Connection join: Stays LOW
Hercules TCP server does not show any connection attempts.
On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.

Nahshon

[Florent Pillet]

Thanks for a good analysis and comparison of different version. We'll look into this,
and fix the issues when appropriate in iViewer 4.

Note, though, that (as I previously mentioned it), connection join never raises for
UDP connections, as it makes no sense. UDP is connection-less, and more importantly,
since UDP is a fire-and-forget method of sending data, there is no ACK from the other
end(s) to confirm that the data has been received.

In other words: do not rely on the UDP system connection join, this is a unreliable
way of doing things.

Florent

[Nahshon Williams]

No more UDP connection joins, understood. . . .
Now trying to downgrade ipad ;-(

[Fiasco]

I use UDP extensively. I find it more responsive. For example, my
directtv receiver is controlled via rs232 with a Moxa. If I use tcp
for button presses there is a slight but noticeable delay that isn't
there with UDP.

Further the Moxa has a limit of 4 simultaneous connections (4 CF
instances) but with UDP universal broadcasts there is no limit.

The same is true for my Onkyo. On the volume slider, volume
transition via dragging is more fluid via UDP

On Jun 11, 3:26 pm, Florent Pillet <fpil...@gmail.com> wrote:
> Thanks for a good analysis and comparison of different version. We'll look into this,
> and fix the issues when appropriate in iViewer 4.
>
> Note, though, that (as I previously mentioned it), connection join never raises for
> UDP connections, as it makes no sense. UDP is connection-less, and more importantly,
> since UDP is a fire-and-forget method of sending data, there is no ACK from the other
> end(s) to confirm that the data has been received.
>
> In other words: do not rely on the UDP system connection join, this is a unreliable
> way of doing things.
>
> Florent
>
> On 11 juin 2011, at 19:58, Nahshon Williams wrote:
>
>
>
> > This is what I have seen so far . . .
>
> > Also on Pastie (in case Google scrambles this up)
> >http://www.pastie.org/2053056
>
> > Multitasking disabled on all iPads.
> > Only one app on one ipad enabled at any time of testing.
> > Using Gui Designer 2.3.4.2
> > Hercules Command: r1call_ack=1$0D
> > Regex: r1call_ack=(1)\x0D
> > There is a timer command sent at the push of a button.
>

> > iOS 4.3.3 Using UDP Maintain connection.255.255.255.255port 4996

>
> > iViewer stable 3.4.2 build 124 Connection:
> > Connection join: goes HIGH
> > On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
> > Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.
>
> > iViewer Next 4.0.2 build 154:
> > Connection join: Stays LOW
> > On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
> > Timer commands: DO NOT TRIGGER and display in the "received data" window in Hercules.
>
> > iOS 4.3.3 Using TCP Maintain connection. Computer IP defined in system properties (to communicate with hercules TCP server)
>
> > iViewer stable 3.4.2 build 124:
> > Connection join: goes High
> > Hercules TCP server shows active connection.
> > On Match regex Response to Hercules Command: TRIGGERS commands as expected.
> > Timer Commands: TRIGGER and display in the "received data" window in Hercules.
> > All is well ;-)
>
> > iViewer Next 4.0.2 build 154:
> > Connection join: Stays LOW
> > Hercules TCP server does not show any connection attempts.
> > On Match regex Response to Hercules Command: DOES NOT trigger commands as expected.
> > Timer commands: DO NOT TRIGGER and display in the "recieved data" window in Hercules.
>

> > iOS 4.2.1 Using UDP Maintain connection.255.255.255.255port 4996

[Florent Pillet]

I'm not saying that you shouldn't be using UDP.
Actually UDP works even better in iViewer 4 than in previous releases
(as does the rest of the networking stack).

My point is just that the "connection" join is meaningless for UDP.

But if you have a valid reason for it to go high, then low, when a
datagram is received, we're not against reinstating it. Just need to
understand the actual requirement, so as to maybe offer a better
solution.

Florent

[Nahshon Williams]

As long as it responds to a real disconnection (device switched off for example) then I see no harm is having it "work" a little caveat maybe to warn the user that it is a virtual join perhaps . . .
Nahshon

[Florent Pillet]

There can't be a notion of "disconnection" with UDP. UDP is a way to
send and receive datagrams without an actual connection. You send a
datagram over the network, with a target, or broadcast, or a multicast
address. You have no way to know whether the target actually received
it. It may or may not have reached its target, you'll never know it.

This is the fundamental thing with UDP: there is _no_ connection. Which
makes it much faster than TCP, because datagrams don't have to be
acknowledged, and there is no connection establishment latency.

So what's the use of a "connection" join? If you need a join to be
triggered high when a datagram is received, I understand and we
can restore this functionality. But really, all you should be relying
upon with UDP is feedback matching.

Now your analysis highlights an issue where TCP connections don't
seem to raise the connected join high when the connection is made:
we'll fix this one. For the other issues you found, I'd like to try
your test GUI so as to have the exact same settings. Can you email
it to me?

Thanks,
Florent

[Nahshon Williams]

I guess I am just thrown by the maintain constant connection check box, that baby threw me when I was trying to communicate btw iPads (I never checked it). . . sending you file now. . .

[Fiasco]

If you want feedback via udp you have to maintain a constant
connection or CF won't be listening for the UDP broadcasts.

You are not really maintaining a constant connection via UDP, your
just leaving CF open to listen for udp broadcasts on the specified ip
address and port.

If you set your udp system to 255.255.255.255, that is a universal
broadcast. And device on the network can listen for and respond to
udp universal broadcasts.

So, say you have a stereo receiver that is connected to the network
and the connection method is a 255 udp broadcast any CF device
listening to 255.255.255.255 on the same port can catch that broadcast
and react to it.

[Florent Pillet]

Ok I initially missed that part.

You are using a broadcast address, and there was a recent change
in the UDP code (to fix another issue) that broke receiving messages
from broadcast and multicast addresses (sending worked, though).

Just fixed that. Will be in TestFlight build 159

Florent

On 11 juin 2011, at 19:58, Nahshon Williams wrote: