3
votes

I am using Winsock class CAsyncSocket in Windows 7 to create a UDP chat program. It simply opens an unconnected UDP socket and allows text strings to be sent to another computer also running the chat program. I'm finding that when my chat program runs on two computers with Ethernet NICs connected with crossover cable (so there's no other network traffic) that whichever computer tries to transmit first it is unsuccessful until after the first datagram is sent from the other computer. In the following screen captures Computer #1 tries to send "test" three times without it being received by Computer #2. Then Computer #2 sends "hello" which is received by #1. Then Computer #1 sends "test" again and this time it is received. Although the three initial transmissions of "test" from #1 appear to not go through they clearly did something for if "hello" from #2 is sent before the "test" message from #1 then the "hello" message is the one that is lost.

Computer #1

Station 1

Computer #2

Station 2

After each computer has successfully send a datagram then all subsequent datagrams are sent and received without a problem. If I close and reopen the socket [Reset Local Port] only on one side then each computer can still send and receive successfully. If I [Reset Local Port] both computers then in most cases the first one to send experiences the same problem but not always. Sometimes even after [Reset Local Port] on both sending and receiving still works. The call to create the unconnected socket is

 Create(i_LocalPort, SOCK_DGRAM, FD_READ, m_LocalSockAddrIn.AddrStr());

And then

CAsyncSocket::SendTo()

to send the datagram. Looking for some hints as to what's going on here.

Update Info: Looking with Wireshark the lost packets do appear to be sent with the appropriate source and destination address but they are not being received by the destination. Datagram Capture

1
Are your NICs configured to use DHCP? If so, the crossover cable is eliminating all possible DHCP servers from your network so neither of them has an IP address, which would explain it. It's not a realistic situation to test.user207421
I resorted to the crossover and static IP addresses to try to eliminate other variables like the network switch not passing datagram or other network traffic causing UDP failure. It was on my local LAN with DHCP where I first saw this same problem.JonN
I am still trying to resolve this issue. I have tested with other UDP Chat programs and have found failures to receive datagrams with these programs also. I am now suspecting the network environment. I tried using udp-win-chat.software.informer.com/download And have had one case where sending and receiving with the isolated network on crossover cable and running WireShark I see the sent datagrams from both sides but neither udpchat program shows as having received anything.JonN
The question remains. Is this a case you really care about? Does it work on a proper network?user207421
From previous comment "It was on my local LAN with DHCP where I first saw this same problem."JonN

1 Answers

2
votes

The problem was caused by Windows Firewall. I turned off the firewall on both computers the problem goes away. Normally Windows brings up a dialog when it blocks access but one of the computers had disabled "Notify me when Windows Firewall blocks a new program" so there was no dialog message. It just silently discarded the Datagram. I expect the reason it allowed Datagrams through after a message was sent is it has an exception to allow receipt from a port that the program has sent to. So after sending to the other port it was possible to receive from it.