Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection
Keeping messages seperate on a connection Keeping messages seperate on a connection
Keeping messages seperate on a connection
Go Back  Xtreme Visual Basic Talk > > > Keeping messages seperate on a connection


Reply
 
Thread Tools Display Modes
  #1  
Old 03-16-2011, 02:45 PM
stokeentertainm's Avatar
stokeentertainm stokeentertainm is offline
Contributor
 
Join Date: Jan 2005
Location: Stoke-on-Trent, UK
Posts: 439
Default Keeping messages seperate on a connection


Hi,

I'm trying TCP communication using VB.NET and using the TcpClient method.

All is working fine but I'm having trouble keeping my message seperate from each other.

For example, my message have an header and footer and can range in size from very small (32 bytes) to quite large (64k). The problem I have is that when messages are being sent quickly they will arrive together. For example, if two 32 byte messages are sent they will arrive as 64 bytes. This is no good as I need to process them seperately.

So my question is:- Is there a way to easily separate my messages using a built in feature of the TcpClient so that the "reading" will give me the correct amount of bytes each time corresponding to the amount of bytes I have sent per message?

Thanks for any help in advance,

Matt.
Reply With Quote
  #2  
Old 03-16-2011, 03:59 PM
AtmaWeapon's Avatar
AtmaWeaponKeeping messages seperate on a connection AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

I'm not going to say it's impossible, but I will say I see no way to configure this on the TcpClient class, you're asking for something that may require Socket-level configuration, and for a well-designed protocol it's a non-issue.

Networking protocols tend to consider data as a stream rather than individual packets. This works great for things like file transfer or HTTP, where a single logical piece of data is being sent via several packets. The layers of abstraction between you and the bits strip out the TCP headers and all you see is a stream of data; it's a heck of a lot easier than being handed a ton of packets from which you have to unwrap TCP headers and IP headers.

When your protocol involves small packets of information, this may not work so well. The forces contending against you aren't confined to TCP though; your network hardware might be part of the process. I'm not counting exact numbers, but the TCP header's something like 24 bytes, and a real packet's also going to include an IP header and some other headers. To network hardware, that makes sending a packet a pretty expensive proposition. I imagine most network hardware has a buffer for data and only sends data when either the buffer is full or some timeout has elapsed. So when you send 32 bits of data, it might get plopped in the buffer and wait a while. If you send another 32 bits over the same connection before the timeout elapsed, as far as the hardware's concerned you're sending 64 bits of data. I could be making this up, but it seems feasible.

Plus, on the receiving end you're still up the creek. TcpClient doesn't expose data as individual received packets; it exposes them as a stream. Even if you can get your data sent out as two individual packets, multiple packets might arrive before you attempt to read data. All TcpClient can tell you is how much data it has; by the time you ask it's tossed the TCP/IP headers that might separate the packets. I believe the only way you can get individual packets is to use the Socket class, set it up to read raw packets, then interpret the TCP/IP headers for the individual packets. If the data is indeed coming in as two packets, this would let you see two packets, though what you'd really see is a bunch of bytes which you then have to interpret to figure out if there was more than one packet or not. Raw sockets requires Administrator privileges and you'll have to deal with corner cases like when you ask for data before a packet has fully arrived. What I'm trying to make clear is using Socket would be dumb, there's a solution that should make you slap your forehead.

Put a size field in your header that indicates the size of the packet. That way, when you receive 64 bytes, you can check the header to see if you have 1 64 byte packet. If not, you'll know how much to read for the first packet and you can process it. Then, you can check the header of the next packet to get its size, and so on until no data remains. This is how TCP solved the problem, and it's a good way to solve the problem in your own protocols.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #3  
Old 03-16-2011, 04:47 PM
stokeentertainm's Avatar
stokeentertainm stokeentertainm is offline
Contributor
 
Join Date: Jan 2005
Location: Stoke-on-Trent, UK
Posts: 439
Default

Great reply, thanks

I feared that would be the case and I will try your suggestion.

Many thanks !!
Reply With Quote
  #4  
Old 03-17-2011, 12:09 PM
stokeentertainm's Avatar
stokeentertainm stokeentertainm is offline
Contributor
 
Join Date: Jan 2005
Location: Stoke-on-Trent, UK
Posts: 439
Default

I tried two ideas, both of which worked.

The first one was the length field which could be checked to see if there was any outstanding data needing to be received.

The second contintinually checked the buffer for the header and footer of my messages and if it was found then it would remove and process that message only and leave the remainder behind to be added to by the ongoing read process.

All good
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection Keeping messages seperate on a connection
Keeping messages seperate on a connection
Keeping messages seperate on a connection
 
Keeping messages seperate on a connection
Keeping messages seperate on a connection
 
-->