Thread: Strange behaviour from Winsock

  1. #1
    Registered User
    Join Date
    Mar 2014
    Posts
    3

    Strange behaviour from Winsock

    I have a PC running XP (or W7, it makes no difference) that has a direct Ethernet connection to a DSP (no routers in the way).
    After reset, the DSP sends BOOTP packets to the PC as it waits to be loaded.
    A C++ program on the PC detects these BOOTP packets using Winpcap. On receiving a BOOTP, the PC sends a small program to the DSP using UDP.
    The PC opens a socket on port 0xC0C0, then starts the DSP, and waits for a packet to come in.
    When the DSP starts, it broadcasts an ARP to find the host then sends it a UDP packet to port 0xC0C0.

    If I run this, it works. The PC detects the BOOTP, loads the DSP, which sends the ARP and gets a response. The DSP sends its UDP packet and the PC gets it.

    If I immediately close down the PC program, reset the DSP and run the PC program again, the PC detects the BOOTP, loads the DSP, which sends the ARP and gets a response, and the DSP sends its UDP packet (all verified by Wireshark on the PC), but the PC program never sees the incoming packet.

    Instead, if I wait a minute or so after a successful run, I can run again without problems (the incoming UDP packet is read correctly).

    I have verified that the data being sent in both directions are always the same on every run.
    All the Winsock calls on the PC execute with success returns.

    It appears that something in Windows is taking a long time (of the order of a minute) to terminate the input socket completely at the end of a run and, in the meantime, it is absorbing incoming packets and discarding them. This must be happening AFTER Windows has happily opened the socket on the same port for the next run.

    As the PC program is shut down between runs, there cannot be any memory of previous runs in the program itself. It must be something strange happening in Windows.

    I have been chasing this problem for a very long time now and I am no closer to a solution.
    Any suggestions would be gratefully received.

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    0xC0C0 is within the range of dynamic points (which operating systems can use when assigning random ports). As such, you are virtually guaranteeing an eventual dispute between the OS and your program over that port.

    Try using a port in the range of registered ports (0x400 to 0xBFFF). Since some operating systems allocate ports in the range 0x400 to 0x1388, you might be better off avoiding those too (I'm not sure offhand if windows does this or not).
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    Non-ephemeral ports are 49152 to 65535 which 0xC0C0 falls in (were you thinking 0x0c0c perhaps?)

    However, non-ephemeral ports on Windows start at 50000. But that is somewhat mitigated due to Windows assigning ephemeral ports from the bottom up.
    If you can't change the port and are always on Windows:
    How to reserve a range of ephemeral ports on a computer that is running Windows Server 2003 or Windows 2000 Server
    You cannot exclude ports by using the ReservedPorts registry key in Windows Server 2008 or in Windows Server 2008 R2

    >> If I immediately close down the PC program, reset the DSP and run the PC program again ...
    When the app closes, are the ports closed properly? Do you have proper error checking after all functions that can return an error?

    gg

  4. #4
    Registered User
    Join Date
    Mar 2014
    Posts
    3
    Quote Originally Posted by grumpy View Post
    0xC0C0 is within the range of dynamic points (which operating systems can use when assigning random ports). As such, you are virtually guaranteeing an eventual dispute between the OS and your program over that port.

    Try using a port in the range of registered ports (0x400 to 0xBFFF). Since some operating systems allocate ports in the range 0x400 to 0x1388, you might be better off avoiding those too (I'm not sure offhand if windows does this or not).
    The port number is actually irrelevant. I get identical behaviour whichever port I use.

  5. #5
    Registered User
    Join Date
    Mar 2014
    Posts
    3
    Quote Originally Posted by Codeplug View Post
    >> If I immediately close down the PC program, reset the DSP and run the PC program again ...
    When the app closes, are the ports closed properly? Do you have proper error checking after all functions that can return an error?
    As I mentioned in my original post, 'All the Winsock calls on the PC execute with success returns.'

  6. #6
    Registered User
    Join Date
    Aug 2003
    Posts
    1,218
    What if you wrap your program in a loop? Basicly do
    Code:
    int main()
    {
        while(1)
        {
            // Rest of program
        }
    }
    Does everything work correctly?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. strange behaviour
    By cfanatic in forum C Programming
    Replies: 41
    Last Post: 10-01-2012, 04:16 PM
  2. strange behaviour
    By cfanatic in forum C Programming
    Replies: 2
    Last Post: 07-16-2012, 06:41 AM
  3. Strange behaviour of GCC
    By BlackOps in forum C Programming
    Replies: 14
    Last Post: 07-29-2009, 06:44 PM
  4. strange behaviour.......
    By surdy in forum C Programming
    Replies: 2
    Last Post: 05-01-2004, 11:50 AM
  5. Strange behaviour
    By PrivatePanic in forum Windows Programming
    Replies: 11
    Last Post: 07-23-2002, 12:54 AM

Tags for this Thread