-2

I am implementing a server in which i listen for the client to connect using the accept socket call.

After the accept happens and I receive the socket, i wait for around 10-15 seconds before making the first recv/send call.

The send calls to the client fails with errno = 32 i.e broken pipe.

Since i don't control the client, i have set socket option *SO_KEEPALIVE* in the accepted socket. 

const int keepAlive = 1;
acceptsock = accept(sock, (struct sockaddr*)&client_addr, &client_addr_length) 
if (setsockopt( acceptsock, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive)) < 0 )
{  
    print(" SO_KEEPALIVE fails"); 
}

Could anyone please tell what may be going wrong here and how can we prevent the client socket from closing ?

NOTE One thing that i want to add here is that if there is no time gap or less than 5 seconds between the accept and send/recv calls, the client server communication occurs as expected.

Rajat
  • 314
  • 4
  • 15
  • In Linux, you can get errno = 32 for error: ENOTCONN also, which means the socket is not connected, and no target has been given. Please see that the syscalls you made before initiating send/recv are not returning errors – Aravind Jun 12 '13 at 12:06
  • 1
    Did you verify that `connect()` actually succeeded, and notified you that a full connection was available, before you then started calling `send()`? Sockets do not normally close themselves after an idle period, and 10-15 seconds is too short a time for `SO_KEEPALIVE` to close a dead connection, and 10-15 seconds is too short a time for an external firewall/router to close an idle connection. So something else is going on. My guess is you are simply not managing your client socket correctly. – Remy Lebeau Jun 12 '13 at 16:47
  • @Aravind and Remy .. Yes the connect() succeeds because accept calls which is blocking gives a valid accpetsock. Moreover the data is received from the client as well twice or thrice before i start getting the error 32. As i have already mentioned i don't own the client and client works if there is no wait between the accept and send/receive calls. – Rajat Jun 13 '13 at 14:23
  • @Rajat - Is the client, an application running in the same computer? What method do you use to wait? Can you please produce some more code here? – Aravind Jun 14 '13 at 06:42

2 Answers2

0

connect(2) and send(2) are two separate system calls the client makes. The first initiates TCP three-way handshake, the second actually queues application data for transmission.

On the server side though, you can start send(2)-ing data to the connected socket immediately after successful accept(2) (i.e. don't forget to check acceptsock against -1).

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • I guess you didn't understand my question. Thanks for the clarification though. Please go through it again. I am doing the check for the acceptsock against -1 and it fails as the socket is a valid one. – Rajat Jun 13 '13 at 14:31
  • You have to explain then what the actual problem is. Add more info like what application-level protocol is used over the sockets, and what you think should be happening. – Nikolai Fetissov Jun 14 '13 at 10:34
0

After the accept happens and I receive the socket, i wait for around 10-15 seconds before making the first recv/send call.

Why? Do you mean that the client takes that long to send the data? or that you just futz around in the server for 10-15s between accept() and recv(), and if so why?

The send calls to the client fails with errno = 32 i.e broken pipe.

So the client has closed the connection.

Since I don't control the client, i have set socket option SO_KEEPALIVE in the accepted socket.

That won't stop the client closing the connection.

Could anyone please tell what may be going wrong here

The client is closing the connection.

and how can we prevent the client socket from closing ?

You can't.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • In short what you want to say is that there is nothing that can be done here. I am waiting because there is some data that needs to be processed which is to be send to the client. So there is no other option but to wait for that data before sending data to client. – Rajat Jun 13 '13 at 14:27
  • @Rajat 'In short' I already said it, in words of my choosing: 'you can't'. Don't tell me what I 'want to say'. I am extremely allergic to that sort of thing. I already said what I wanted to say, and I am not in need of any paraphrase. I note that you haven't answered any of my questions. – user207421 Apr 28 '16 at 11:33