I have a C socket client program where one thread is for receiving data and another for sending. If the server shuts down then the sender gets EPIPE. If I reconnect the same socket then it can receive data but the sender still gets EPIPE.
How to fix this?
Update:
Actually sender seems to send data as I see number of byte sent. But errno is still set to broken pipe. Before I only checked errno. Shouldn't it be changed to successful?
If I reconnect the same socket then it can receive data but the sender still gets EPIPE.
That can only mean that the sender is still sending via the old socket; also that you haven't closed the old socket.
sender seems to send data as I see number of byte sent. But errno is still set to broken pipe. Before I only checked errno. Shouldn't it be changed to successful?
No. It is only valid to check errno when an immediately prior system call has returned -1. Example:
int rc = send(...);
if (rc < 0)
{
if (errno == EWOULDBLOCK) // or EAGAIN *and* we are in non-blocking mode
{
// queue the write and return to the select() loop
}
else
{
perror("send"); // for example
}
}
else
{
// write succeeded ...
}
Related
I have a main program that generates a few threads (using a while loop with accept() to get clients), and one that all it has to do is "listen to the keyboard" and when the user enters the word exit it will close the entire program.
first, the main program create the listening thread, then it enters a while loop that accept the clients. even if the listening thread get the exit input the loop is still stuck on accept.
i don't have to use a seperate thread to listen to the keyboard but i could'nt find a none blocking way that would work.
the listening thread:
DWORD WINAPI ListenService(LPVOID lpParam)
{
char buffer[5];
if (EOF == scanf("%s", buffer))
{
printf("faile get word from keyboard\n");
}
if (buffer[4] != '\0')
strcat(buffer, "\0");
if (STRINGS_ARE_EQUAL(buffer, "exit"))
{
return 999;
}
return -1;
}
in the main code:
ThreadListen = CreateThread(NULL,0,ListenService,NULL,0,&(ThreadId));
while(1)
{
SOCKET AcceptSocket = accept(MainSocket, NULL, NULL);
if (AcceptSocket == INVALID_SOCKET)
{
printf("Accepting connection with client failed, error %ld\n", WSAGetLastError());
CleanupWorkerThreads();
WSACleanup();
}
printf("Client Connected.\n");
}
There are many different ways you can handle this.
You can abort a blocked accept() by simply closing the listening socket.
Or, you can use select() with a short timeout to detect when a new client is waiting before then calling accept(). You can check your exit condition in between calls to select(). Just be aware that there is a small race condition where a client may disconnect between the time select() and accect() are called, so accept() may still block, if there are no more clients waiting.
Or, you can get rid of your threads and just use non-blocking sockets in a single thread, checking your exit condition periodically in between socket operations.
Or, you can use asynchronous sockets, using WSACreateEvent(), WSAEventSelect(), and WSAWaitForMultipleEvents() to detect socket activity. Then you can create an addition event to wait on for when the exit condition happens.
Or, you can use an I/O Completion Port to handle socket activity, and then you can post a custom exit packet into the IOCP queue using PostQueuedCompletionStatus() to "wake up" any waiting threads.
I am aware that select() will be triggered whenever there is a data in the registered socket buffer.
what will happen if there is a delay between these two statements.
FD_SET(listener, &read_fds); // &
(select(fdmax+1, &read_fds, NULL, NULL, NULL) == -1)
what will happen if packet arrives between these two statements?
//create socket and listen for packets &
FD_SET(listener, &read_fds);
Assume that recv() is done once select is triggered.
What will happen if a packet arrives before the select() call is
made.?
does FD_ISSET still detects the packet which is already in
socket buffer or it will be detected only if new packet arrives and
select gets triggered?
Sample code:
// add the listener to the master set
FD_SET(listener, &master);
// keep track of the biggest file descriptor
fdmax = listener; // so far, it's this one
// main loop
for(;;) {
read_fds = master; // copy it
if (select(fdmax+1, &read_fds, NULL, NULL, NULL) == -1) {
perror("select");
exit(4);
}
// run through the existing connections looking for data to read
for(i = 0; i <= fdmax; i++) {
if (FD_ISSET(i, &read_fds)) { // we got one!!
Understanding gap between socket creation and select() system call
There is no gap between socket creation and select() in your question.
I am aware that select() will be triggered whenever there is a data in the registered socket buffer.
That's true for read events and it applies to the socket receive buffer of connected sockets. It also triggers when there is an inbound connection on a listening socket, or room in the socket send buffer for send events.
what will happen if there is a delay between these two statements.
FD_SET(listener, &read_fds); // &
(select(fdmax+1, &read_fds, NULL, NULL, NULL) == -1)
Nothing bad. Any event that occurs between them will still be signalled. But the first statement isn't a socket creation, contrary to your title.
what will happen if packet arrives between these two statements?
//create socket and listen for packets &
FD_SET(listener, &read_fds);
The socket send buffer exists from the moment the socket is created, so the data will go into the buffer, so when select() runs it will see that and trigger a read event.
Assume that recv() is done once select is triggered.
What will happen if a packet arrives before the select() call is made.?
The socket send buffer exists from the moment the socket is created, so the data will go into the buffer, so when select() runs it will see that and trigger a read event.
does FD_ISSET still detects the packet which is already in socket buffer
Yes.
or it will be detected only if new packet arrives and select gets triggered?
It will always be detected.
If data is waiting to be read, select will return immediately, and FD_ISSET will return true for the file descriptor that the data arrived on. It doesn't matter if data arrived before or after select was called.
select() completes immediately if one or more of the watched conditions is already active; otherwise it blocks until one or more of the watched conditions becomes active (or the timeout, if specified, expires).
I am making a multi-threaded TCP server, when I use recv() in the threads, they do not update/execute/run infinitely (looping), unless recv() actually receives some data.
Here is a code snippet from inside the loop.
if( seconds < 15 ){
printf("%f seconds passed: \r", seconds);
if ( (read_size = recv(sock , client_message , 512 , 0)) > 0 )
{
//Send the message back to client
reply_message = client_message;
(void)write(sock, reply_message, strlen(reply_message));
}
}else{
// ... blah blah blah
}
If I comment out the internal IF statement, the thread runs & outputs printf() as fast as it can. When the IF statement is included, the thread waits on recv() and will not update ( printf() isn't printed ) until recv() has received data :/
Any ideas?
From recv(2) - Linux man page (see here):
If no messages are available at the socket, the receive calls wait for
a message to arrive, unless the socket is nonblocking (see fcntl(2)),
in which case the value -1 is returned and the external variable errno
is set to EAGAIN or EWOULDBLOCK. The receive calls normally return any
data available, up to the requested amount, rather than waiting for
receipt of the full amount requested.
So it's the way how recv works. If you want it to return immediately you should use non-blocking mode (see fcntl and select desriptions).
// sock is the socket you want to make non-blocking
int status = fcntl(sock, F_SETFL, fcntl(sock, F_GETFL, 0) | O_NONBLOCK);
// handle the error
if(status == -1) {
...
}
If you want to check if there anything to read in socket
int count = 0;
ioctl(sock, FIONREAD, &count);
count is the number of bytes available in the socket
I need to perform some operations only after the time a TCP connection is fully closed, that's to say - all the data segments, as well as the finishing routine (FIN-ACK or RST) have been performed and done, and no packets will be sent on the wires.
Since closesocket() is not synchronous and could return before a full close of the connection and socket, I've used the SO_LINGER option to get the moment of closing.
According to the instructions in the MSDN for closesocket, and to the fact that my socket is non-blocking (and thus asynchronous), I wrote this code:
int ret;
/* config 2 secs of linger */
struct linger lng = {1, 2};
setsockopt(s, SOL_SOCKET, SO_LINGER, (const char*)&lng, sizeof(lng));
/* graceful close of TCP (FIN-ACK for both sides) */
shutdown(s, SD_BOTH);
/* linger routine for asynchronous sockets according to msdn */
do {
ret = closesocket(s);
} while (ret == SOCKET_ERROR && WSAGetLastError() == WSAEWOULDBLOCK);
/* my code to be run immediately after all the traffic */
printf("code to run after closing");
However, the closesocket call returns zero (success; instead of getting into the loop) and I see in Wireshark that my final printing is called before all the packets were sent, so - it looks like the linger isn't working.
By the way, the functions I used to open and connect the asynchronous socket were socket(), WSAIoctl() and its lpfnConnectEx() callback.
What's the reason that the lingered closesocket return before a full finish of the TCP connection? Is there a solution?
int rc = poll(fds, 1, -1);
let us say the remote peer goes down. socket breaks here.
In this case will the poll system call return -1 or
will return > 0 and report the disconnect as an error event on the FD.
Also, what would poll return on 0 timeout.
int rc = poll(fds, nfds, 0);
No it doesn't. All it knows is that something happened on the socket, and whether that was a read event, a write event, or an error event. Peer disconnect counts as a read event.
If the sockets breaks, poll() will return > 0, then you will have to check the return value of recv in order to know if the socket is disconnected (recv() will return 0 in this case).
Also, what would poll return on 0 timeout. int rc = poll(fds, nfds,
0);
poll() will return immediately, and the return value can be >= 0.
You really should read the poll() manpage, there is all you need to know.
From the man page:
The field revents is an output parameter, filled by the kernel with the events
that actually occurred. The bits returned in revents can include any of those
specified in events, or one of the values POLLERR, POLLHUP, or POLLNVAL.
(These three bits are meaningless in the events field, and will be set in the
revents field whenever the corresponding condition is true.)
If none of the events requested (and no error) has occurred for any of the file
descriptors, then poll() blocks until one of the events occurs.
Return Value
On success, a positive number is returned; this is the number of structures which
have nonzero revents fields (in other words, those descriptors with events or
errors reported). A value of 0 indicates that the call timed out and no file
descriptors were ready. On error, -1 is returned, and errno is set appropriately.
So, it clear says that if there is an error in the FD return value > 0 and the revents field is filled with the appropiate value. POLLERR for example.