locked
Connecting and closing a TCP Session + time delay RRS feed

  • Question

  • Hi Everyone,

    What are best guidelines when starting/terminating a TCP session?  This is the code that I am using to read the temperature from chamber:


            private void btnReadTemp_Click(object sender, EventArgs e)
            {
                try
                {
                    // Creates the Socket to send data over a TCP connection.
                    s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
                    Thread.Sleep(250);

                    if (!s.Connected)
                    {
                        //Connect to Chamber Controller at IP address 192.168.4.32, TCP port 8888
                        s.Connect("192.168.4.32", "8888");
                        Thread.Sleep(250);
                    }
                }
                catch (Exception ex)
                {
                    MessageBox.Show("Exception caught!!!");
                    MessageBox.Show("Source : " + ex.Source);
                    MessageBox.Show("Message : " + ex.Message);
                }

                //PVAR1? requests the Process Variable for Channel 1
                //Refer to Thermotron Chamber Controller Manual for rest of I/O commands for your model
                command = ASCIIEncoding.ASCII.GetBytes("PVAR1?\r\n");

                //Send the Query Command
                s.Send(command);

                //Receive response
                len = s.Receive(received);

                //Convert received ASCII bytes to string
                temp = ASCIIEncoding.ASCII.GetString(received, 0, len);

                listBox1.Items.Add("Current Chamber Temperature: " + temp);

                //Close socket
                s.Close();
            }

    Questions:
    1.  Do I need to have a time delay as is shown above (250mS)?
    2.  Is this the right way to check if the session is active (connected)?
    3.  Is it OK to close the session every time at the end of this routine?
    4.  If the session is closed every time as shown above, then is this code OK to run a second or as many times, without any connection errors or timeouts?
    5.  Is there a better way to perform this fuction?

    Thanks very much,
    xplorer2k



    Tuesday, April 21, 2009 12:56 AM

Answers

  • 1. No, you do not need this time delay. You also don't need the second time delay. In fact, anytime you see "Thread.Sleep", the code is probably doing something wrong.
    2. You don't need to check if the socket is connected. Usually, you never have to. If Connect() completes successfully, it will be connected; if it has an error, then it won't be.
    3. Yes. Several protocols do this, though if this is called very quickly you may want to keep it open just for efficiency.
    4. Sort of. The code is OK to run many times, but connection errors and timeouts are always possible. The code itself won't make them more likely (unless it's called an extreme number of times very quickly).
    5. I prefer asynchronous socket calls, personally. They allow your GUI to remain responsive even if the temperature monitor gets unplugged.

            -Steve
    • Proposed as answer by Stephen ClearyMVP Tuesday, April 21, 2009 6:43 PM
    • Marked as answer by xplorer2k Tuesday, April 21, 2009 10:13 PM
    Tuesday, April 21, 2009 6:43 PM
  • I recommend you pick up a socket library I wrote:
      http://www.codeplex.com/NitoAsync

    The normal asynchronous sockets make use of the thread pool, which takes a bit of practice to use correctly. The TcpClient and TcpServer classes in my library provide events when data arrives, etc. They're easier to use from GUI code.

    I also have some sample code here:
      http://code.msdn.microsoft.com/NitoSockets
    though you'll have to modify it for the protocol your temperature device is expecting. You'll need the LowLevel sample, not the Simple sample (the Simple sample uses a specific binary protocol wrapper, which your temperature device would not understand).

            -Steve
    • Marked as answer by xplorer2k Wednesday, April 22, 2009 3:18 PM
    Wednesday, April 22, 2009 2:46 AM

All replies

  • 1. No, you do not need this time delay. You also don't need the second time delay. In fact, anytime you see "Thread.Sleep", the code is probably doing something wrong.
    2. You don't need to check if the socket is connected. Usually, you never have to. If Connect() completes successfully, it will be connected; if it has an error, then it won't be.
    3. Yes. Several protocols do this, though if this is called very quickly you may want to keep it open just for efficiency.
    4. Sort of. The code is OK to run many times, but connection errors and timeouts are always possible. The code itself won't make them more likely (unless it's called an extreme number of times very quickly).
    5. I prefer asynchronous socket calls, personally. They allow your GUI to remain responsive even if the temperature monitor gets unplugged.

            -Steve
    • Proposed as answer by Stephen ClearyMVP Tuesday, April 21, 2009 6:43 PM
    • Marked as answer by xplorer2k Tuesday, April 21, 2009 10:13 PM
    Tuesday, April 21, 2009 6:43 PM
  • Thanks Steve,

    Could you please advise how to change the code to have an asynchronous socket calls?

    Thanks again,

    xplorer2k
    Tuesday, April 21, 2009 10:15 PM
  • I recommend you pick up a socket library I wrote:
      http://www.codeplex.com/NitoAsync

    The normal asynchronous sockets make use of the thread pool, which takes a bit of practice to use correctly. The TcpClient and TcpServer classes in my library provide events when data arrives, etc. They're easier to use from GUI code.

    I also have some sample code here:
      http://code.msdn.microsoft.com/NitoSockets
    though you'll have to modify it for the protocol your temperature device is expecting. You'll need the LowLevel sample, not the Simple sample (the Simple sample uses a specific binary protocol wrapper, which your temperature device would not understand).

            -Steve
    • Marked as answer by xplorer2k Wednesday, April 22, 2009 3:18 PM
    Wednesday, April 22, 2009 2:46 AM
  • Thanks Steve, for providing great insight to this subject.  I would look into the information provided.

    Thanks again,

    xplorer2k
    Wednesday, April 22, 2009 3:20 PM