0

I have a server client application that I am currently working on. The server is receiving data fine over a WAN and the client seems to receive the data, but the client is only receiving one communication. Is there anything over a WAN that would make a client always only receive the first return UDP communication and none of the subsequent. Thanks for the help.

Client UDP Listening code

private void receiveUDP()
    {
        System.Net.IPEndPoint test = new System.Net.IPEndPoint(System.Net.IPAddress.Any,UDP_PORT_NUMBER);
        System.Net.EndPoint serverIP = (System.Net.EndPoint)test;
        server.Bind(serverIP);
        //server.Ttl = 50;

        EndPoint RemoteServ = (EndPoint)listenUDP;
        do
        {
            byte[] content = new byte[1024];
            int data = server.ReceiveFrom(content, ref RemoteServ);

            string message = Encoding.ASCII.GetString(content);


            ProcessCommands(message);


        } while (true);
    }
Stephen
  • 174
  • 4
  • 14
  • Hard to say. Can you post the code of your client program? – Hunter McMillen Aug 14 '11 at 23:45
  • @Hunter McMillen Edited to include the clients listening code. If you need to see more let me know and I will post more of it. – Stephen Aug 14 '11 at 23:51
  • This is by design. Any of the many machines between the transmitter and the receiver is allowed to drop packets without a diagnostic. Impossible to find out who and why. Use TCP if you can't deal with this. – Hans Passant Aug 15 '11 at 01:16
  • @iandotkelly listenUDP is defined earlier as an IPEndPoint with an address of the server and any port. – Stephen Aug 15 '11 at 02:22
  • @Hans Passant UDP is the only choice here as this is a prototype for a multiplayer game server. And I understand the UDP is designed to allow dropped packets. But the drop of packets here is not random. EVERY packet after the first is not received leading me to believe I have made a programming or configuration error rather than a poor choice in protocols. – Stephen Aug 15 '11 at 02:22
  • any exceptions happening, perhaps in ProcessCommands ? what is the value of data ? – Yahia Aug 15 '11 at 03:53
  • @Yahia The data doesn't seem to be hanging in ProcessCommands. If I send the same data through a TCP connection it does not behave the same although the data itself is the same. – Stephen Aug 15 '11 at 04:26
  • @Stephen: I am asking about the value of variable `data` (check with a debugger or do some logging) and if any exceptions happen (i.e. you don't have exception handling in the loop, check with debugger or do some logging) ? – Yahia Aug 15 '11 at 04:28
  • @Yahia I have checked the data with a debugger. It is being received correctly and is the correct info. The listening loop continues after the first message, but following that message nothing more is received. – Stephen Aug 15 '11 at 04:36
  • what you write contradicts http://msdn.microsoft.com/en-us/library/wdfskwcy.aspx - UDP is connectionless, either your loop block on the line with `ReceiveFrom` call (blocking mode) till next data is available OR you get a SocketException when no data is available (non-blocking-mode) ! – Yahia Aug 15 '11 at 04:41
  • @Yahia I know that UDP is a connectionless protocol. My loop block waits to receive data from the specified location in ReceiveFrom. I do not get a SocketException after receiving a packet I do not receive any more... – Stephen Aug 15 '11 at 04:58
  • 1
    have you verified that the server actually sends some data after the first packet ? can you check with Wireshark or similar to see what happens on the network ? – Yahia Aug 15 '11 at 05:05
  • @Yahia Yeah I have verified that the server sends the data to the client on the same IP and Port that the client sent on. Nothing should change between the first transmission and the next which is where my confusion lies. – Stephen Aug 15 '11 at 05:11
  • 1
    ok... everything you write says that it should work and that there no symptoms other then the missing data... excluding the theorectical option (some subtle part of the information given being not accurate) this means either we miss some important piece of information here (either code and/or error messages and/or some Wireshark-diagnosed anomaly) or it is just that UDP is not reliable for some reason in your specific network configuration (i.e. blocked by some firewall) – Yahia Aug 15 '11 at 05:15
  • @Yahia I agree with your assessment. That is why I am confused. A firewall should not block the data because the first message gets through, the message itself does not affect the message being transmitted, and If it was simply UDP unreliability then I would think that I would see random data arriving not just always the very first reply and none after that. If you need to see all of the code the link to it is in a comment after the answer on this page. – Stephen Aug 15 '11 at 05:24
  • the first message coming through doesn't mean the next messages can't be blocked by the firewall... it can depend for example on the time between the two messages (if this is long enough then the "hole" will be closed again) – Yahia Aug 15 '11 at 05:29
  • @Yahia According to the WireShark timestamps the time between transmissions is almost identical. There is nothing to indicate a real difference that would make a difference but I will run some quick tests to see if I send data quicker to make a difference. – Stephen Aug 15 '11 at 05:40
  • @Yahia No luck on my test. Immediately sending a response on the arrival of a client packet yielded the same results. The very first message made it through and the rest did not. – Stephen Aug 15 '11 at 06:08
  • what of you make the client send answer for a packet and then send the next packet ? – Yahia Aug 15 '11 at 10:49
  • @Yahia The client currently sends 3 packets to the servers 1. All of the server transmissions rely on the client sending information and then the server processing that information before returning it to all of the clients. I am only testing right now though with 1 client so I can time all of the responses. – Stephen Aug 15 '11 at 13:53

1 Answers1

1

This is a bit of a stab in the dark (since you don't provide enough code to really say what's going on definitively), but there's one major reason why you might consistently see some UDP datagrams not be delivered over a WAN, while others always arrive successfully. This reason is MTU; the Maximum Transmission Unit which can be sent in a single UDP datagram. This can easily produce behaviour such as what you're seeing if (for example), your first datagram is a short "I accept your connection" message, and you then follow that with a datagrams containing large files; the first (small) datagram is smaller than the MTU and is delivered, while the following (large) datagrams are larger than the MTU, and are discarded en route.

For UDP over a WAN, the MTU will not be higher than about 1500 bytes, and in many situations may be as low as 1200 bytes. Any packets larger than that will be silently dropped somewhere between endpoints. To send large blocks of data via UDP, you need to chop them up into pieces smaller than the MTU for the network segment across which you're transmitting them.

On a LAN, you can usually get away with sending datagrams of any size. But as soon as they're being sent over the Internet or otherwise through heterogenous networks, they're likely to be silently discarded.

If you do need to send large files, you might choose to transmit them via TCP instead; TCP automatically manages chopping data up to fit within the MTU, and ensures that its packets are all received, and are received in order; guarantees that you will not receive from datagrams sent via UDP.

As I mentioned above, this is a complete stab in the dark and may not actually be related to your actual troubles. But it's the elephant in the room, when all we have to go on is that the first packet always arrives successfully, and later packets never do.

Trevor Powell
  • 1,154
  • 9
  • 20
  • I dont believe that this is the issue. All of the packets I am sending are approximately the same size. But I will check into it. As far as the code if it would help to see more here is a link to a previous question I posted that has the majority of the connection specific code for my server: http://stackoverflow.com/questions/7018796/tcp-udp-socket-server-on-wan – Stephen Aug 15 '11 at 03:27
  • @Stephen did you fix your issue? – Neil Barnwell Aug 07 '13 at 08:16
  • @NeilBarnwell I actually did eventually. I ended up asking another question about basically the same topic and was able to resolve my issues. Here is the link to the question I asked: http://stackoverflow.com/questions/7020996/tcp-and-udp-socket-server-on-a-wan If you are trying to solve this problem too read through the comments and the answer on that question. – Stephen Aug 08 '13 at 01:12