SFML community forums
Help => Network => Topic started by: zac on January 20, 2009, 06:48:01 pm
-
Hey - I seem to be receiving a SIGPIPE from within SocketTCP::Send - it means that you try to write to a socket without a reader - the default reaction is to terminate the application.
This is what happens to my server if the client kills the connection before everything is ready. At first, a FIN packet is sent, but the server does not react to it properly. Then, when the server is trying to write again (because Send did not return Socket::Error but Socket::NotReady from within Send), it really sends the data (normal PSH packet), but all it gets is the RST packet from the obviously already closed client socket.
And then, the server process receives a "SIGPIPE" signal and is terminating.
I'm working with Non-Blocking sockets.
A possible workaround:
Add "signal(SIGPIPE,SIG_IGN);" to the SocketHelper initialisation for Linux.
I would also suggest to test the return value when you are sending the packet size in SocketTCP::Send(const sf::Packet&).
-
Maybe this will help:
Linux.die.net:
When writing onto a connection-oriented socket that has been shut down (by the local or the remote end) SIGPIPE is sent to the writing process and EPIPE is returned. The signal is not sent when the write call specified the MSG_NOSIGNAL flag.
Maybe you should use this flag?
-
...or handle the signal.
-
Yes, but I like the solution with the flag best. It is easy to test if this flag is available and it doesn't take the user of the library the freedom to handle the signal himself...