Udp so_reuseaddr

[kolkoo]

I have this problem. Have an application ( Warcraft III ) that uses udp broadcasts for lan management , usually when you run the application two times and join the LAN with one you can't join with the other because bind fails, so I hooked bind and used the SO_REUSEADDR option and that worked I was able to join LAN with both clients, now when I create a game broadcast packets are sent from both clients to retrieve games, notify for game creation, etc. The problem is that normal behaviour would be: broadcast is sent by a client and is received by the other clients since they are on different machines different addresses but now sometimes client that used sendto also ends up getting the recvfrom and eating up the data. I've tried several things the one that works best is just not binding on the client that is hosting so everything it sends gets to the other client (that has already bound ) and you can see games created etc. The downside to this is if you create game with [bound client], [not bound client] does not recv anything since [bound client] eats up the data again (and for some reason that doesn't work in vista - i'm testing on both machines) . Now the question is- > is there any way to bind two applications on the same pc on the same port and somehow make sure that they don't eat up the sent data by themselves or any other solution that would allow them both to communicate through udp at that port without problems.


EDIT: I'm pretty certain there is no real winsock based solution to this but I decided to ask anyway.
My other idea is to have the data sent over inbetween the processes through some form of IPC and then just call the packet processing functions in the different clients upon needed data arrival.


EDIT2: Well I implemented it using a shared memory between processes to transfer packets and calling the packet processing functions directly, still if anyone knows a winsock based solution that 'd be great

[Richard.J]

If a socket is bound to a port by one process, no other process can bind to this port using the same protocol (UDP in your case).
The socket option SO_REUSEADDR only has one single reason: if you have a server that has bound a special port and this server crashes, the underlying IP stack blocks this port for a while (in a TIME_WAIT state). If you try to restart the server during this time, it will fail because the port is still "unavailable". Using SO_REUSEADDR kind of overrides that state and makes the new server instance able to use the port again immediately.
Starting two instances of the same app simultaneously results in "undefined behaviour". I have done some tests a few years ago with TCP connections and I can tell that you really can't predict what will happen to those two apps. They continue running without errors, but you don't know which app will receive packets etc.
Conclusion: don't do it.

HTH,
Richard