I'm having problems reconnecting nonblocking tcp sockets bound to the same source port... (winsock using standard Berkeley calls) sorry I'll backup & try & make more sense: When the socket is first created I allow winsock so assign me a free port I then save the assigned port & set the socket into nonblocking mode The first connect() on this socket always succeeds After the connection succeeds & is ended (or fails) the socket is closed Another socket is then immediately created in its place & assigned the same port & attempts to connect() to the same host (& target port) again Now sometimes this works fine & the sockets establish their connections, receive the allotted packets, disconnect, then repeat But other times the source port seems to become invalidated after the first connect() & all later socket connects bound to the same source port will fail with an eventual connect() timeout This socket invalidation only seems to occour directly after the first connect 99% of the time (it does occasionally occour after several, but this is highly rare) All winsock socket calls are fully error checked & it reports no problem whatsoever on rebinding of the same port, nor should it I believe The server is in a blocking accept loop & receives no input whatsoever while the client slowly times out with its connect() call If anyone has experienced these symptoms before or feels they could shed some light on this it would be fully appreciated oh btw: all sockets (client & server) are currently being shutdown() with SD_BOTH prior to closesocket() & are being closed serverside [Edited by - ProPuke on June 24, 2005 3:58:02 PM]

My app uses the port as a form of identifaction

I've tried enabling SO_REUSEPORT, but to no avail. You see the port's not actually in use. If it were then it would report an error upon bind

The ports in constant TIME_WAIT status :/


Well really I was just posting this in the hope that soembody else had had the same problem, I guess not

Thanks for taking the time to reply anyways Kylotan

The option is called SO_REUSEADDR, and you must have set it on the socket that goes away to allow a new socket to bind to the same port before the TIME_WAIT state is exited. Typically, you'll stay in TIME_WAIT for more than a minute; this behavior is there to be able to respond to possible stray/late packets intended for the original connection.

So:
1) enable SO_REUSEADDR
2) take a coffee break, to avoid previous binds without SO_REUSEADDS to time out
3) from now on, you should be able to re-bind as often as you want (assuming the original listener is closed)

Sorry I also meant SO_REUSEADDR
& sadly no, it doesn't solve the current situation
There doesn't appear to be any problem with the binding, nor with any other function calls
They all issue perfectly
It's just that the nonblocking connect() eventually just times out after the first connection is closed

Thanks anyway hplus0603,
I think I'll just go rhythmically beat my head against this wall :/

Does the receiving end keep calling accept() on the initially created socket? Do you keep handling new sockets created by accept()?

The server is in a blocking accept loop, yes
But while the clients connect() is timing out the server is still sitting @ accept with no word from any new connections

extra:
just to expand on that - I can start extra clients while the first one is timing out & they can still connect fine (well they're guarenteed to connect fine the first time anyways, later ones may fail)
I can also restart the server, but as long the client continues to try to use the same sourceport it will always timeout

[Edited by - ProPuke on June 25, 2005 11:08:49 AM]

thanks nevernomore

dang I remember looking @ the shutdown SO_LINGER option too, damn I should of tryed it
But really thinking about it now it probally wouldn't of been the wisest of choices anyway
TCP connection sockets are best left alone once they're done I think (they kinda scare me)
Yeah I just changed port between each tcp master server ping, problem is the port used when doing that was used to mark what udp port the client was also listening on, so I had to introduce port shuffling to the udp clients.. anyways I'm rambling

It's done now & the project is going forward again
Thanks for taking the time everyone

I've just one question though.. Why is it that winsock allows you to bind to ports that are still listening? I mean they're useless to work with aren't they?
What would be the point in allowing new sockets to bind to them?

Well cheers guys ;]