closesocket(luiClientSocket);Does socket disconnect finish sending first?
Author
In my game, when players die a message is sent to them letting them know they died. However, its rather unsuccessful at letting them know, which leads me to my question...
If I call...
Per MSDN:
Note, looking up the function will generally tell you about it's behavior.
Quote:
The closesocket function closes a socket. Use it to release the socket descriptor s so that further references to s fail with the error WSAENOTSOCK. If this is the last reference to an underlying socket, the associated naming information and queued data are discarded. Any pending blocking, asynchronous calls issued by any thread in this process are canceled without posting any notification messages.
.
.
.
Note To assure that all data is sent and received on a connection, an application should call shutdown before calling closesocket (see Graceful shutdown, linger options, and socket closure for more information). Also note, an FD_CLOSE network event is not posted after closesocket is called.
Note, looking up the function will generally tell you about it's behavior.
Author
Thanks.
I skimmed though the MSDN pages, and I'm finding the methods of closure not too relieving for the solution I'm after: I wanted to be able to closesocket() forcefully, and have Winsock automatically handle in the background, the completion of the packets currently in tranmission.
In my current code, after I call closesocket() I set my 'client' structure to 'available' and another player has the potential to join in immedietely. If by gracefully closing, the socket must wait a period of time before accepting new connections, than I'm facing a rather tedius programming challenge.
I'll end up introducing an "lucClientInGame" variable into my client structure. When a player is killed, this value will become zero and a timer inside the client structure will start counting down. The client will have three seconds to recieve all information before an ungraceful shutdown of the socket.
It sounds straightforward to me to do it this way, but if anyone has a better idea... [rolleyes]
I skimmed though the MSDN pages, and I'm finding the methods of closure not too relieving for the solution I'm after: I wanted to be able to closesocket() forcefully, and have Winsock automatically handle in the background, the completion of the packets currently in tranmission.
In my current code, after I call closesocket() I set my 'client' structure to 'available' and another player has the potential to join in immedietely. If by gracefully closing, the socket must wait a period of time before accepting new connections, than I'm facing a rather tedius programming challenge.
I'll end up introducing an "lucClientInGame" variable into my client structure. When a player is killed, this value will become zero and a timer inside the client structure will start counting down. The client will have three seconds to recieve all information before an ungraceful shutdown of the socket.
It sounds straightforward to me to do it this way, but if anyone has a better idea... [rolleyes]
More from MSDN:
Quote:Here is a summary of closesocket behavior:So from that, and the rest of what I read, by default it will do exactly what you want. Though it also said you should call shutdown as well anyway.
if SO_DONTLINGER enabled (the default setting) it always returns immediately – connection is gracefully closed "in the background"
if SO_LINGER enabled with a zero time-out: it always returns immediately - connection is reset/terminated
if SO_LINGER enabled with nonzero time-out:
– with blocking socket it blocks until all data sent or time-out expires
– with nonblocking socket it returns immediately indicating failure
Why do you have to close the socket anyway?
I'd keep it open until the player wants to disconnect or times out of a re-join.
I'd keep it open until the player wants to disconnect or times out of a re-join.
Author
Sorry for the long bump, someone on my residence had a virus and Rogers shut us down for quite a while. I got my internet back on Friday, and just remembered this thread.
No.
MSDN specifies...
What I explicitly stated was...
Therefor, the SO_DONTLINGER by default, does not do exactly what I wanted to do.
Quote:Original post by iMalc
More from MSDN:Quote:Here is a summary of closesocket behavior:So from that, and the rest of what I read, by default it will do exactly what you want. Though it also said you should call shutdown as well anyway.
if SO_DONTLINGER enabled (the default setting) it always returns immediately – connection is gracefully closed "in the background"
if SO_LINGER enabled with a zero time-out: it always returns immediately - connection is reset/terminated
if SO_LINGER enabled with nonzero time-out:
– with blocking socket it blocks until all data sent or time-out expires
– with nonblocking socket it returns immediately indicating failure
No.
MSDN specifies...
Quote:"In [the SO_DONTLINGER] case, the Windows Sockets provider cannot release the socket and other resources for an arbitrary period, thus affecting applications that expect to use all available sockets. This is the default behavior (SO_DONTLINGER is set by default)."
What I explicitly stated was...
Quote:"In my current code, after I call closesocket() I set my 'client' structure to 'available' and another player has the potential to join in immedietely. If by gracefully closing, the socket must wait a period of time before accepting new connections, than I'm facing a rather tedius programming challenge."
Therefor, the SO_DONTLINGER by default, does not do exactly what I wanted to do.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
