CODEWITHSUNDEEP
socketstcpserversocket
Haris
Haris

Reputation: 14053

Socket programming Client Connect

I am working with client-server programming I am referring this link and my server is successfully running.

  1. I need to send data continuously to the server.
  2. I don't want to connect() every time before sending each packet. So for first time I just created a socket and send the first packet, the rest of the data I just used write() function to write data to the socket.

But my problem is while sending data continuously if the server is not there or my Ethernet is disabled still it successfully write data to socket.

Is there any method by which I can create socket only at once and send data continuously with knowing server failure?.

The main reason for doing like this that, on the server side I am using GPRS modem and on each time when call connect() function for each packet the modem get hanged.

For creating socket I using below code

Gprs_sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (Gprs_sockfd < 0)
{
  Display("ERROR opening socket");
  return 0;
}
server = gethostbyname((const char*)ip_address);
if (server == NULL)
{               
  Display("ERROR, no such host");                
  return 0;
}

bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr,(char *)&serv_addr.sin_addr.s_addr,server->h_length);
serv_addr.sin_port = htons(portno);
if (connect(Gprs_sockfd,(struct sockaddr *) &serv_addr,sizeof(serv_addr)) < 0)
{
  Display("ERROR connecting");
  return 0;
}

And each time I writing to the socket using the below code

n = write(Gprs_sockfd,data,length);
if(n<0)
{
  Display("ERROR writing to socket");
  return 0;
}

Thanks in advance.............

Upvotes: 1

Views: 336

Answers (2)

tomasz
tomasz

Reputation: 13072

Nikolai is correct here, the behaviour you experience here is desirable as basically you could continue transfering data after network outage without any logic in your application. If your application should detect outages longer that specified amount of time, you need to add heartbeating into your protocol. This is standard way of solving the problem. It can also allow you for detect situation when network is all right, receiver is alive, but it has deadlocked (due to to a software bug).

Heartbeating could be as simple as mentioned by Nikolai -- sending a small packet every X seconds; if the server can't see the packet for N*X seconds, the connection would be dropped.

Upvotes: 0

Nikolai Fetissov
Nikolai Fetissov

Reputation: 84239

TCP was designed to tolerate temporary failures. It does byte sequencing, acknowledgments, and, if necessary, retransmissions. All unacknowledged data is buffered inside the kernel network stack. If I remember correctly the default is three re-transmission attempts (somebody correct me if I'm wrong) with exponential back-off timeouts. That quickly adds up to dozens of seconds, if not minutes.

My suggestion would be to design application-level acknowledgments into your protocol, meaning the server would send a short reply saying that it received that much data up to now, say every second. If the client does not receive suck ack in say 3 seconds, the client knows the connection is unusable and can close it. By the way, this is easier done with non-blocking sockets and polling functions like select(2) or poll(2).

Edit 0:

I think this would be very relevant here - "The ultimate SO_LINGER page, or: why is my tcp not reliable".

Upvotes: 1

Related Questions