tags:

views:

979

answers:

2

I am trying to connect to a piece of hardware via TCP/IP. I had done this very smoothly in VB and am trying to achieve the same result in C#.

The code looks like this:

internal Socket connectSocket(IPEndPoint vIPEndPoint)
    {
     Socket lclSocket = new Socket(vIPEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);


      try
      {
       lclSocket.Connect(vIPEndPoint);
      }
      catch (Exception ex)
      {

      }

     if (lclSocket.Connected)
     {
      string str = receiveResponse(lclSocket);

      if (str.Contains(PFCommonVariables.m_strCommandDelimiter))
      {
       _sockets.Add(vIPEndPoint, lclSocket);
      }
      else
      {
       lclSocket.Disconnect(true);
      }
     }

     lclSocket.ReceiveTimeout = RECEIVE_TIMEOUT;
     lclSocket.SendTimeout = SEND_TIMEOUT;

     return lclSocket;
    }

As I said, this code is exactly the same as the code in VB, and there I can keep a succesful connection. THe problem here in C# is that right after the 'socket.Connect' call that I make to the IPEndPoint, the Connected property is shown to be True. I verify successful sending and receiving of data thru Wireshark also. Then, I put a breakpoint at the if(lclSocket.Connected) statement. When I first come here, the Connected property is still True. However, if I wait here for 1-2 seconds without doing anything, the Connected property becomes false.

So, the connection is lost automatically. Then, if I keep the debugger on and wait on a line, in Wireshark I see numerous Keep-Alive TCP messages being sent regularly back and forth between the PC and the Hardware. I am not sue what these are but they may help diagnose the problem...

A: 

When you put a breakpoint at the lclSocket.Connected line, you are connected to the server. At that point it appears the server is going to send you a response from connecting based on your following code. Is your server going to disconnect you for not responding to that response in a ample amount of time?

Also for tcp traffic you might want to look into the tcpclient class.

Will
No, the remote end is 'dumb' in the sense that it doesn't check for any responses or has timeouts. The PC should stay connected until a disconnect call. The VB version of the code, which is exactly the same, works like expected and does not disconnect. Also there seem to be no packets sent indicating the disconnect.
sbenderli
A: 

I've been digging deeper into this and it seems that the Connected property of the Socket class does not necessarily return values we would expect. I found a similar post here:

http://bytes.com/topic/c-sharp/answers/258127-how-use-socket-connected-property-properly

It seems that there may be a state of half-open, which I suspect that I am in. The problem happens when I try to receive the message being sent from the hardware. The message indeed comes, however, my receive loop doesn't terminate due to another problem. However, since the hardware sent the message, I believe the TCP protocol assumes the connection is at a halt and sets the Connected property to false.

I assume that this happens exactly the same in VB, although since my receive function workek correctly there, I never observed the change in the Connected Property. When the socket.Connected is false, one should be able to still send messages.. It's worth checking out.

sbenderli