.NET Framework - TCP Send with Response

Asked By Scott

23-Jan-10 10:26 AM

I have to send a TCP stream to a device.  The device returns a response and
I cannot figure out how to catch the response.   I know the device response
properly because if I connect to it using HyperTerminal I can send the
command and immediately the response is displayed back to me in
HyperTerminal.  Now I need to do this programmatically.  The send portion of
the code below works because the device response properly but for some
reason I am unable to catch the response.  I have looked through MANY examples
online and they all seem to look like this code block.

Please help, and thanks in advance.
Scott
(kc7dji@gmail.com)




System.Net.Sockets.TcpClient tcpClient = new System.Net.Sockets.TcpClient();

tcpClient.Connect(LED_IP, LED_Port);
System.Net.Sockets.NetworkStream networkStream =
tcpClient.GetStream();



// Does a simple write.
Byte[] sendBytes = Encoding.ASCII.GetBytes(LED_Stream);
Byte[] RecvBytes = new Byte[4096];


networkStream.Write(sendBytes, 0, sendBytes.Length);

String responseData = String.Empty;
Int32 bytes = networkStream.Read(RecvBytes,
RecvBytes.Length, 0);
responseData =
System.Text.Encoding.ASCII.GetString(RecvBytes, 0, bytes);

this.txtResult.Text = bytes.ToString() + ": " +
responseData;


networkStream.Flush();

tcpClient.NoDelay = true;
tcpClient.Close();

tcpClient = null;
networkStream = null;

23-Jan-10 10:43 AM

Ok I have already found a portion of my problem.  I had 2 parameters switched
on the Read command.

Wrong:
Int32 bytes = networkStream.Read(RecvBytes,  RecvBytes.Length, 0);

Correct:
Int32 bytes = networkStream.Read(RecvBytes, 0,  RecvBytes.Length);


Now my last problem is that I am getting a few bytes of data back but not all
of it.  Like it is happening too fast.  I am getting 3-5 bytes when I should
be getting about 20.

Any Ideas?

23-Jan-10 10:48 AM

wow... I have fought this for 3 days.... today must be a good day because I
have it working now.

I just put the thread to sleep for 100 ms and it all works as expected.

23-Jan-10 12:41 PM

It may work, but you did not fix it correctly.  And as a general rule,
using Thread.Sleep() or similar is never the correct way to fix network
i/o problems.

The most obvious problem in your code is that you are only calling
Read() once.  TCP provides no guarantees at all about how many bytes a
given call to Read() will return.  In only guarantees that bytes you
receive will be received in the same order in which they were sent.

You must call Read() repeatedly until you have received as much data as is
required.

Pete

24-Jan-10 08:57 PM

It provides a couple more guarantees than that.
It also guarantees that the data will not be duplicated, nor lost
without an error. This is supplementary to, but not the same as
receiving data in the same order as sent.

Also, when Read returns and there was no error and
the sender has not closed the stream, the read count must be >= 1.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

25-Jan-10 05:34 AM

Or you have seen the terminating character, or no data has been sent for
N milliseconds, or whatever, for your particular application, means
TCP, I could issue a "read record" request, and the receiver would
read exactly as much data as the sender sent.  Nowadays, the concept
of record has pretty much gone away, everything is just a byte stream,
and every networking application gets to create its own communications
protocol.  it is so much simpler.  Not.)

25-Jan-10 12:19 PM

IMHO, those ALL fall under the description "as much data as is
required".  :)

(In the old days, using DecNET instead of

Only the prevalence of TCP/IP makes it seem like it is that way.  There
are lots of other protocols to choose from, if you do not need to go over
the Internet, and many of them support connection-oriented, reliable,
message-based communications.

Pete

25-Jan-10 08:42 PM

RMS over DECNet is record oriented.

And even $QIO(W) with DECnet pass length.

Arne

25-Jan-10 11:27 PM

Sure, my point is that I have not used DECnet for decades; it is all TCP
these days.