3

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

JonN
  • 2,498
  • 5
  • 33
  • 49
  • 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 Jan 16 '15 at 00:04
  • 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 Jan 16 '15 at 00:35
  • 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 http://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 Jan 28 '15 at 21:56
  • The question remains. Is this a case you really care about? Does it work on a proper network? – user207421 Jan 28 '15 at 23:46
  • From previous comment "It was on my local LAN with DHCP where I first saw this same problem." – JonN Jan 28 '15 at 23:49
  • So that's what you should have been investigating, as your answer shows. Classic XY problem. NB That comment should have been incorporated into the question. – user207421 Jan 29 '15 at 01:34
  • Yes it would have been quicker to investigate the firewall 1st but when I posed the question I didn't know the answer. I was lead to investigate the firewall only after eliminating the other possibilities of network switch issue or network traffic which using static IP addresses and a direct wire connection did. I agree it's desirable to investigate the actual solution but then we ask questions because we don't know the solution at the time we ask the question. Also the inconsistent nature of the received data due to the firewalls rules initially pointed to something other than firewall. – JonN Jan 29 '15 at 20:55

1 Answers1

2

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.

JonN
  • 2,498
  • 5
  • 33
  • 49
  • After reading your question, I was all excited to suggest disabling Windows Firewall and get me a 50 point bounty. Drat. ;) As you've noticed, Windows Firewall doesn't allow inbound connections by default. Since UDP isn't a stateful protocol, it takes an outgoing packet to mean that you've established an outgoing connection. – Zenexer Feb 04 '15 at 21:40