Bug with ofxUDPManager

Ok, this is a little strange, first I will set the use- It is common when communicating with UDP servers to send a hello message to initiate communication. The hello message contains the address information of the sender- the server has a single open port lets say 9910, but no specified port to return communication on.

No problem, the first hello message contains a source port (lets say 5320), this source port will be bound on the client machine and in a usual UDP setup this socket is now ready to receive messages, and the server knows (by reading the address information) where to reply to. Nice and easy.

If you do not specify a source port then one is picked randomly from the stack and the datagram is bound to this port (this port is now no longer available).

OfxUdpManager has a very weird bug, if we do this

fakeClient.Create();
fakeClient.SetReuseAddress(true);
fakeClient.Bind(5320);
fakeClient.Connect("192.168.1.100", 9910);

We should be able to send a message on port 9910 with a source port of 5320. To test this safely I set up 2 apps on the “server machine” one just printing what it receives on port 9910, the other sending a date and time string to the client address on port 5320.

The messages from the client to the server come through fine and checking them with wireshark they have the source address, then I can send a response from the server- the client receives the response perfectly.

***But now it breaks, after the first response from the server any messages from the client will then have a new source port and the server obviously will not see them.

No permutation of order of initialisation or setReuseAddress seem to have any effect.

I am very curious if anyone has run into this, or has any fixes/comments

And of course I am not smart enough to fix it myself and would really like it to work as my current project depends on it. But I guess that is always the way.

Cheers

Fred

Maybe you can try with this:

I have been trying with that and discussing it with Trent. Although it is threaded and has some nice features it is also setup to work only with separate sockets for sending and receiving (ie the source port of a sent message cannot be used to receive messages on as it should be). Same problem as above, but the OF ofxUdpManager does come much closer to working, it actually functions until the client receives a message.

Cheers

Fred

Here is a very clear explanation of the datagram structure we should be able to achieve- don’t be fooled by the title.