TCP Server, No response to incoming SYN packet


tonyjflavell

Recommended Posts

Hi

I have set up a TCP server. I want to receive packet data on an incoming port, then reply. So my port is set up as a TCP server listening on port 44444. I initialise the port like this:

Device.GPRS_TCP_Com.UnlockPort()

Device.GPRS_TCP_Com.InitComm();

Then I wait in a loop ( with delays), reading and printing out anything that arrives with this command:

respChar = ""

respChar = device.GPRS_TCP_Com.Read( 0 )

Nothing arrives.

Looking at the interface using wireshark I see this:

36

Link to comment
Share on other sites

What OS are you running? It appears to be a rather funny bug, most likely OS related. The code hasn't changed in years, and yet it appears that data gets delayed for some reason on Win7x64 at least, and yet, when we recompile the same code on a newer compiler, it works flawlessly. To confirm this, though, I'd like to know if you are also on Win7x64.

BTW: also to confirm, what we see is that the comms coming in from the client is delayed getting to DF. The test I ran was to create a server on port 80 and then browse to my machine. After some time I get part of the HTTP request, and then after more of a delay, the rest (sometimes). Is this what you see?

Link to comment
Share on other sites

Just to clarify what I am trying to do.

The server listens on a port

I expect the server to respond to s a SYN packet and establish TCP comms

I believe that this server does not handle multiple connections, so i can simply read from it or write to it once it is connected to the client.

After it has received the SYN ACK packet the client will send a bespoke binary message in a packet

I expect to be able to pick it up on the server with read commands.

I then expect to send a reply packet ( again binary data) with a write command.

Link to comment
Share on other sites

You'll get that Unable to bind error if you already have software running as a server on that port, perhaps IIS or Apache, or some other software. You can always use port 88 and then put :88 after the IP in the browser.

DAQFactory should be able to do this without a problem, but there is obviously some sort of OS issue with Win7x64, probably to do with the socket implementation our current compiler is using since the exact same DAQFactory code works properly on Win7x64 under a newer version of Visual C++. This is the first incompatibility I've seen, and now that we know its an OS incompatibility, we may be able to fix it under the current compiler. Worse case, we'd have to run under the newer compiler, but we have not finished testing the port to the new compiler.

Link to comment
Share on other sites

  • 4 weeks later...

Is probably worth recording the result of this investigation. i.e. The TCP Server was working. But it listens on the main PC Ethernet interface only. I was trying to listen on another (OpenVPN tunnel) interface. Basically Daqfactory cant do this, but will always listen on the main interface.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.