How to receive bytes through tcpclient or sockets?

PatM

Well-known member
Joined
Dec 5, 2012
Messages
52
Programming Experience
10+
Under VB6 with winsock I spend half a day writing an app that receives a plain old byte array that was mostly text but also had control characters. Under VB.net I've been trying for four days to do the same thing without success.

I stole a client server example from MS Windows Simple Multi-User TCP/IP Client/Server Example sample in VB.NET for Visual Studio 2010 and used the client portion (the server is actually a piece of hardware, nothing I can change). This almost works but it appears the encoding is mangling the stream and I can't figure out how to stop it. I triend encoding.default (example uses acii I think) with no luck.

I also thought why bother with passing strings between the connection class and main app but I really can't figure out how. Why something so simple in VB6 has to be so mind destroyingly difficult in .net is beyond me. I was finally starting to get to like vb.net too.

Can anyone point to an example that uses simple byte arrays or give me a clue as to how to modify this one?

Thanks!

Edit: I should clarify.. The data coming in is 8 bit ascii and looks something like this

<first byte values as a command sequence>
200
15
8
9
<then text>
serial: # 12356
version: 2.83.1
blah blah blah
<final byte value meaning end of message>
5

EOLs are chr(10)

When I get these through vb.net the EOLs are messed up, I end up with data after the chr(5) etc. In VB6 with winsock the message comes in perfect.y
 
Last edited:
The bytes received is written to bBuffer array that you passed to BeginRead. It's up to you how to manage that from there. You can pass it through the state parameter along with any other state information if you wish, if you have more that one object you want to pass along you have to write a class to hold all that. In callback the user state is available in AsyncState property of IAsyncResult.
 
Oops, hit the wrong key and editing went weird! - starting again below

You mean the last parameter, that I almost always see set to "Nothing" or the stream being used, can be set to bBuffer and then the IASyncResult.ASyncState will actually be bBuffer? e.g.

myNetStream.BeginRead(bBuffer,0,bBuffer.Length,bBuffer)

then in the callback
VB.NET:
Private myCallBack(ar as IASyncResult)

  Dim intBytesRead as Integer = myNetStream.EndRead(ar)
  Dmi bBytes as Byte = ar.ASyncState

Or there's probably a casting for ar.ASyncState and I think I remember something about DirectCast() that I'll look up.

I'll experiment with this ASAP. THANKS!
 
You mean the last parameter
Yes, state parameter.
docs said:
state
Type: System.Object

An object that contains any additional user-defined data.
there's probably a casting for ar.ASyncState
Yes, it is type Object, so you have to CType/DirectCast that into the type of object put there.
me said:
if you have more that one object you want to pass along you have to write a class to hold all that
While writing a class with two properties is just about two lines of code, you could also use a Tuple(Of T1,T2) for that.
 
Yeah I figured out that CType Array works great. It worked without casting too but that's cause the language does it's best to figure out what you intended rather than what you actually wrote. I used the cast anyway since I'm trying to get my habits upgraded.

I found out also that firing beginread from a button with the expectation of data then using DataAvailable in the callback to fire another Beginread isn't the best idea. My parsing is so fast that there's no data ready when it finishes even though another batch of data is on the way - so no beginread happens and I miss the second batch.

I'll go back to starting a beginread as soon as the connection is made then starting another every time I finish with a batch of received data. Shouldn't miss anything then... Though I should look up the timeouts so if nothing comes in when I'm expecting more data the app won't simply hang there forever.

I'm having lots of fun now 8) Thanks very much!
 
Back
Top