SDL_net Socket listeners not unique?

As many of you are likely aware, setting up a listening socket with
SDL_net entails using SDLNet_ResolveHost and SDLNet_TCP_Open like so:

IPaddress ipAddressListener;
int iPort = 80;
if (SDLNet_ResolveHost(&ipAddressListener,NULL,iPort) == -1)
{
// error
}

TCPsocket tcpSocketListener = SDLNet_TCP_Open(&ipAddressListener);
if (!tcpSocketListener)
{
// error
}

The trouble with this is that, unlike other TCP socket APIs, opening up
a listening socket on some port, say 80, does not acquire exclusive
access to the port. In other words, I can run multiple instances of a
server application listening on the same port using this code, and they
will not conflict. Even more oddly, client connections occur on any of
the running servers in a seemingly ad-hoc basis! What’s going on here?
Should’t SDLNet_ResolveHost / SDLNet_TCP_Open fail if the port is
already taken?

Regards,
Colin

Wow, that’s certainly different. I haven’t observed this under windows or
linux, what are you using?On September 18, 2005 04:58 pm, Colin Vella wrote:

The trouble with this is that, unlike other TCP socket APIs, opening up
a listening socket on some port, say 80, does not acquire exclusive
access to the port.

The trouble with this is that, unlike other TCP socket APIs, opening up
a listening socket on some port, say 80, does not acquire exclusive
access to the port.

Wow, that’s certainly different. I haven’t observed this under windows or
linux, what are you using?

Windows XP Pro
SDL 1.2.8 + SDL_net 1.2.5
VS.NET 2003 / VC++7

I just accidentally did the same thing as you on Windows 2000, and yes indeed
one can open multiple server sockets on the same port! Must be a bug in
SDL_net, though I haven’t been able to find it… mayby we should bug the
author.On September 19, 2005 03:02 pm, Colin Vella wrote:

Windows XP Pro
SDL 1.2.8 + SDL_net 1.2.5
VS.NET 2003 / VC++7

I accidentally did the same thing as you on Windows 2000,
and yes indeed one can open multiple server sockets on the
same port! Must be a bug in SDL_net, though I haven’t been
able to find it… mayby we should bug the author.

According to the FAQ, bug reports should be sent on the main
mailing list, so I guess our work is done.

The trouble with this is that, unlike other TCP socket APIs, opening
up a listening socket on some port, say 80, does not acquire
exclusive access to the port. In other words, I can run multiple
instances of a server application listening on the same port using
this code, and they will not conflict. Even more oddly, client
connections occur on any of the running servers in a seemingly ad-hoc
basis! What’s going on here? Should’t SDLNet_ResolveHost /
SDLNet_TCP_Open fail if the port is already taken?

This is not a bug SDL_net. You should read about the socket option
SO_REUSEADDR which SDL_net uses of course for server sockets.

Also it might introduce a security risk for operating systems that allow
multiple bindings of reserved ports without superuser privileges.
I don’t know if that is the case for win32.

Jon DanielOn Mon, 19 Sep 2005 00:58:36 +0200 Colin Vella wrote:

For TCP sockets SO_REUSEADDR allows multiple bindings to the same
address only if all the other sockets bound to that address and port are
busy in a TIME_WAIT state. Arbitrary multiple bindings to the same
port are only allowed with different addresses or with UDP.

Jon DanielOn Thu, 22 Sep 2005 11:50:51 +0200 Jon Daniel <@Jon_Daniel> wrote:

Ok I just checked it with win32 and it seems that it allows multiple
server to bind to the same port with the same address there. And servers
seem to be able to just reuse the port after they have been restarted
even without SO_REUSEADDR. So this option is not needed at all for non
POSIX conform win32.
So it is a bug in SDL_net but it is easily fixed by adding a
#ifndef(WIN32) int SDLnetTCP.c around the related setsockopt.

Jon Daniel

I just accidentally did the same thing as you on Windows 2000, and yes indeed
one can open multiple server sockets on the same port! Must be a bug in
SDL_net, though I haven’t been able to find it… mayby we should bug the
author.

WinSock and BSD sockets let you do this if you specify SO_REUSEADDR to
setsockopt(), which SDL_net happens to do if you are binding to either
INADDR_NONE (255.255.255.255) or INADDR_ANY (0.0.0.0).

The previous example passed a NULL to SDLNet_ResolveHost(), which
returns INADDR_ANY.

My understanding is that this is there so that you don’t have to wait
for the previous socket to die out if you are starting and stopping the
program that binds the socket a lot (such as, say, when debugging a
server) and obviously only affects listen sockets.

I think the last time I ran into this (a LONG time ago), Windows would
just toss connections to the different sockets seemingly randomly (and
for UDP sockets, toss individual PACKETS to the different connections
randomly!)…I can’t remember what Linux did. Not sure if that’s
actually true and/or different due to my flakey memory and Windows
service packs.

The quickest fix is “just don’t bind the same port twice”.

–ryan.

Please read my postings regarding this issue it is really a bug in
SDL_net because Win32 doesn’t need SO_REUSEADDR in order to be able to
restart a server on the same address and port if the socket is in a
TIME_WAIT state. SO_REUSEADDR allows for complete duplicate bindings on
the same port there which is not the desired feature here.

I’ve attached a patch which will fix it.

Jon Daniel
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_netTCP_c.patch
Type: text/x-patch
Size: 655 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050927/8ef44694/attachment.bin

I’ve attached a patch which will fix it.

This is in CVS, thanks!

–ryan.