1

I wrote a c++ windows process (Win7 if it matters) that can send and receive packets using sendto and recvfrom, but unfortunately not all of the packets are read from the socket. Both of the computers are directly connected and transmitting bi-directionally 2000 packets (1 packet per second, 500bit each), when I open WireShark I can see that the 2000 packets got to the destination but for some reason my process reads from the socket less than 2000 (~1980 packets). The recvfrom function is in a task that runs as long as the process is alive. What could be the reason that the packet gets to the destination but my process didn't receive it? Is there a problem with my code or a known problem with recvfrom or maybe is it because it's udp? There are no errors involved, this is part of the code:

Update: the problem was with the socket configuration. When i opened it i used setsockopt SO_RCVTIMO of 1 second, changed 1 to 100000 microsecond and it fixed the problem. 

    socklen_t sockaddr_in_len = sizeof(sockaddr_in);  
    nResult = recvfrom(s,
                              buff,
                              buffLen,
                              0,
                              (sockaddr*)sender,
                              &sockaddr_in_len);  
        SAFE_UINT ulError = WSAGetLastError();



        if (nResult == -1)  


{  
    if(ulError != WSAETIMEDOUT)  
        {   
            Sleep(100);  
            switch (ulError)  
            {  
                case WSAECONNRESET:  
                    //Print error     
                    return S_OK;  
                case WSAEINTR:  
                    //Print error  
                    return S_OK;  
                case WSAENOTSOCK:  
    //Print error  
                    return S_OK;   
                case WSAENOTCONN:  
                    //Print error  
                    return S_OK;   
                default:  
                    //Print error  
                    return S_OK;   
            }  
        }  
        else  
        {  
            //Print error  
            return S_OK;   
        }  
    }  
    else if (nResult == 0)  
    {  
        //Print error  
        return S_OK;  
    }
Shani.M
  • 29
  • 3
  • 1
    Since you use `recvfrom` I assume you're using UDP? – Some programmer dude Jan 18 '18 at 14:10
  • I don't see a loop round `recvfrom`. `recvfrom` can receive partial/split packets and you need to reassemble them before passing the whole packet(s) up to your next layer. You need to check the value in `nResult` to determine now much `recvfrom` actually received. – Richard Critten Jan 18 '18 at 14:16
  • 2
    @RichardCritten That's only a problem with TCP. With UDP you receive a full packet (possibly delayed and out of order) or you don't. – Some programmer dude Jan 18 '18 at 14:21
  • It’s indeed UDP and I do use a loop, I just didn’t copy it :) as I explained, 1980 out of the 2000 packets are read (sometimes less and sometimes 2000/2000). – Shani.M Jan 18 '18 at 14:28
  • 1
    I don't think there's any guarantee that your process will receive a UDP datagram just because it reached the machine. – molbdnilo Jan 18 '18 at 14:31
  • @molbdnilo What do you mean? – Shani.M Jan 18 '18 at 14:34
  • 2
    Why are you using `Sleep(100)`? Please show the complete loop containing the `recvfrom` call. – G.M. Jan 18 '18 at 14:37
  • 1
    As you should know, UDP is a protocol without any delivery guarantees. Packets can and will get lost. Exactly when and where that happens doesn't matter. It might be in a router between the two hosts, or it might be inside the local computer between the hardware interface and your program. – Some programmer dude Jan 18 '18 at 14:46
  • The loop is a while(true) loop. The missing packets are usually after a few hundreds and none of the errors appear. Do you think maybe I’m missing something? maybe nResult>0 but “unreadable” for some reason? – Shani.M Jan 18 '18 at 14:48
  • 1
    @Shani.M UDP does not guarantee delivery. If you want guarantees, you need to implement your own protocol on top of UDP, or switch to TCP/IP and implement a packet protocol on top of that. – molbdnilo Jan 18 '18 at 14:56
  • 1
    Please state your question as a question - it's unclear what you are asking. – Danny Varod Jan 18 '18 at 16:51
  • @Danny Varod My question is what could be the reason that the packet gets to the destination but my process didn't receive it? Is there a problem with my code or a known problem with recvfrom or maybe is it because it's udp? – Shani.M Jan 19 '18 at 15:03
  • 1
    Then edit the question, don't write this as a comment. – Danny Varod Jan 20 '18 at 16:01
  • Why are you treating a timeout as a success? – user207421 Jan 21 '18 at 22:55

0 Answers0