-1

The situation i have is Linux client is using UDP Socket. Client is sending message and in case no response within 10 seconds , Client will retry again in 10 seconds intervals.

The case is when connection is down , many trials are sent from client at the same time nothing was received on server side . Once the connection is up i found all previous messages are received at the same moment on server which means it was buffered and it causes a lot of problems because of duplicated messages received on the same moment on server side .

TCPDUMP ON client Side:

21:01:14.691903 IP 172.123.13211 > 172.34.13211: length 88  "1st at second 14"  
21:01:24.692791 IP 172.123.13211 > 172.34.13211: length 88  "2nd at second 24"  
21:01:34.694930 IP 172.123.13211 > 172.34.13211: length 88  "3rd at second 34"  
21:01:44.696020 IP 172.123.13211 > 172.34.13211: length 88  "4th  ate second 44"

Server TCPDUMP once the connection is up : 

12:02:01.509518 IP 172.123.13211 > 13211: length 88 "Received 1st at second 1"       
12:02:01.517841 IP 172.123.13211 > 13211: length 88 "Received 2nd at second 1"    
12:02:01.543759 IP 172.123.13211 > 13211  length 88 "Received 3rd at second 1"    
12:02:01.550741 IP 13211 > 172.123.13211: length 36   
12:02:01.567948 IP 172.123.13211 > .13211: length 88

I need to understand in case of UDP socket is used and Connection is down . how to avoid buffering packets during shortage

Client Code is in C++ Thank you

Heba
  • 1
  • 2
  • 2
    'Using UDP connection' and 'once the connection is up' and 'connection is down' have no meaning. There is no such thing as a UDP connection. – user207421 Jun 27 '18 at 10:12
  • You said that in your question. No need to merely repeat it. Doesn't add anything. – user207421 Jun 27 '18 at 10:33
  • 1
    Part of UDP programming is dealing with duplicate messages; these can happen in other scenarios as well, so even if you solve this problem you'll still want to handle duplicates gracefully. One easy(ish) way to handle them is to just insert the incoming UDP packets into a keyed data structure, based on a key that will be the same for any duplicate packets (e.g. source IP address?), and then, only when you've read the in the entire backlog of packets, iterate over the data structure, handle the packets it holds, and clear it. – Jeremy Friesner Jun 28 '18 at 14:12
  • @JeremyFriesner, yes Server can handle duplicate messages , but Server is complaining that he receive the message many times on the same moment and they said they never get the same behavior any client even all are using UDP. When i tried to close the socket , data are cleared , but i need another way to clear buffered data on socket without closing it. Thank you – Heba Jul 02 '18 at 10:36
  • You can’t clear It afaik but you could reduce its size via setsockopt(SO_SNDBUF); that would reduce the problem, perhaps – Jeremy Friesner Jul 02 '18 at 16:26
  • @JeremyFriesner . I'm using so_reuseaddr . Please confirm is that normal to send packet with 10 seconds delay between them and to received all packet at the same moment on server ? – Heba Jul 03 '18 at 10:20
  • Dunno what "normal" means, but I've only seen that behavior on programs that have failed to call recv() over the last 10 seconds, allowing packets to pile up in their UDP socket's receive-buffer. – Jeremy Friesner Jul 03 '18 at 14:47

1 Answers1

0

you might be looking for this :

How to flush Input Buffer of an UDP Socket in C?

Also the language you have used in the question is wrong. Please be more clean and precise and use relevant terminology

yashC
  • 887
  • 7
  • 20
  • Thank yash, Kindly the problem is client is sending packets to server but because connection is down ,server is not receiving any packets, Once the connect is up i found all buffered packets are received at same moment . I have checked the link and i believe the clearing out the buffer should be done on server side not client side , right ? – Heba Jun 27 '18 at 11:41
  • if you are implementing this in C then what flags are you setting for sendto() function ? – yashC Jun 27 '18 at 11:50
  • Client code is in C++ int UdpSocket::SendTo( void *_data, int _length, const InetAddress &_remoteAddress ) const { int writeLength; do { writeLength = sendto( handle, (char *)_data, _length, 0, (struct sockaddr *)&_remoteAddress, sizeof(_remoteAddress)); } while( writeLength < 0 && LastError() == EAGAIN); if( writeLength < 0 ) { throw SocketException( LastErrorAsText()); } return writeLength; } – Heba Jun 27 '18 at 12:14
  • When the connection is up and you start receiving the package , Is the client program still running then ? – yashC Jun 27 '18 at 13:28
  • Yes, Client is up – Heba Jun 27 '18 at 13:36
  • You are not receiving buffered up package then. From what I can understand, the client is in while loop then and so what you are receiving is new packages. Try changing "&&" condition in while to "||". and add some `couts` to see where your program really is – yashC Jun 27 '18 at 13:39
  • program traces shows the same as tcpdump , every 10 seconds new message is sent in case no response from server. I need to understand UDP socket is caching data ?If yes, how to clear the cache before sending new packet? What exactly the problem in client ? Thank you – Heba Jun 28 '18 at 12:49
  • UPD does not retry by itself unless you implement a retry mechanism on application later. UPD will sent the packet even if you have no hardware layer so to say. – yashC Jun 28 '18 at 13:02
  • Yes YashC, Client is retransmitting data, But i need to know how to clear data cached in Socket ? to avoid receiving many packets at the same time on Receiver. I tried to clear the data by closing the socket , at this point caches data are not received on Server but i need another way to clear without closing socket – Heba Jul 02 '18 at 10:25
  • @Heba I dont think the issue is cached data (because there is no data cache mechanism for UDP, at least I can not find any), to avoid packet overflow on the server side, the simplest method is to implement a sleep/delay, after sending each packet on the client side. – yashC Jul 03 '18 at 05:28