Re: NetworkStreams impractical?, Buffering NetworkStreams, how?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Yechezkal Gutfreund (sgutfreund_at_hotmail.com)
Date: 07/05/04 

Date: Mon, 5 Jul 2004 09:59:33 -0400

Option #1 is not robust, since headers can also be fragmented across reads.

Option #2 was what I was looking for. Basically, it means you write your own
BufferedStream for the
CF. I guess I was hoping for a revelation that there was something there I
was not seeing. But you are correct,
writing one's own BufferedStream is not RocketScience.

The only thing to note is that without this, network streams cannot be made
robust. So, why did MS not put BufferedStreams to begin with into the Net
CF?

Probably most people are relying on short packets fitting in an TCP MTU,
which is not a safe thing, (especially if one is doing wireless
communication).

"Paul G. Tobey [eMVP]" <ptobey_no_spam@instrument_no_spam.com> wrote in
message news:eJSIftEYEHA.1684@tk2msftngp13.phx.gbl...
> I think that you're looking at it the wrong way. The network data *does*
> appear as a stream (not as a set of discrete packets). The best way to
> write your protocol, if you have control over that is to send a header
> before you send your 'packet'. The header can contain whatever
information
> you want, but should include the length of the packet which is to follow.
> On the receiving end, you can always assume that the first thing that will
> come across will be a header, so you read that many bytes (you don't care
> whether the header actually comes across as a single packet or a hundred
> packets; that's entirely hidden from you). Once you have the header, you
> know how many bytes are to follow, so you receive that many. Again, you
> don't care whether the actual data comes in one packet or fifty. When the
> receive completes, you know that you have the packet contents. You can
then
> return to waiting for a header, etc.
>
> If you don't have control over your protocol and it was written what I
would
> call incorrectly, you can buffer the data yourself, allowing push-back, if
> you want. That is, you'd create a class which encapsulates the network
> stream, has send(), receive(), connect(), etc. methods, maybe, but adds
the
> ability to push data back. When data is pushed back, you need to store it
in
> some memory buffer in your class. When a receive is done while there is
> data in the push-back buffer, you return that data first, then, when the
> push-back buffer is empty, return to getting your data from the network
> stream.
>
> Paul T.
>
> "Yechezkal Gutfreund" <sgutfreund@hotmail.com> wrote in message
> news:e0yiy4DYEHA.3300@TK2MSFTNGP09.phx.gbl...
> > For practical purposes, the CF network stream is really not a stream at
> all.
> > You can't peek, you can't push things back on the stream, etc.
> >
> > We are sending packets on the stream with packet seperation marks,
> >
> > The problem is that one can easily do a read that gets half of two
> packets,
> > or other malignant cases. We would like to read just as much to get the
> tail
> > of the first packet (and match it with what we read) and leave the
second
> > packet on the stream till the rest arrives.
> >
> > Logically, this is buffered stream.
> >
> > The problem is that BufferedStreams are not supported in CF, nor is
peek,
> or
> > seek, which would allow us to set the stream pointer to the actual
logical
> > packet break.
> >
> > What are people doing to get around this limitation?
> >
> >
> >
> > --
> > ==================================
> > Yechezkal Gutfreund
> > Chief Scientist
> > Kesser Technical Group, Inc.
> > ==================================
> >
> >
>
>

Relevant Pages

  • Re: Fundamentals question, is this how it works?
    ... Note the packet may be partially received when you get ... That is what i thought i was saying that it receives it all in a stream ... receving the buffer size each time. ... receiving that many bytes i then break and wait for the next set of data ...
    (microsoft.public.win32.programmer.networks)
  • Re: Fundamentals question, is this how it works?
    ... Knowin when that second packet started is my problem. ... process a TCP stream. ... receving the buffer size each time. ... then the receiving side might ...
    (microsoft.public.win32.programmer.networks)
  • Problems with TCP/IP read requests and bidirectional traffic under W2K
    ... I use an overlapped ReadFile approach to read at first 6 Bytes from a TCP stream ... (these 6 Bytes represent a packet header), from this header the length of the rest of a packet is computed and then ... A colleague told me that he had similar problems when using that "read short part of stream/read long part of stream" approach? ...
    (microsoft.public.win32.programmer.networks)
  • Re: NetworkStreams impractical?, Buffering NetworkStreams, how?
    ... unless you have a *huge* header or a very small actual transmission ... > writing one's own BufferedStream is not RocketScience. ... >> whether the header actually comes across as a single packet or a hundred ... >> stream. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Finding start and end of data in a stream
    ... saw a situation where the buffer was nearly all full of 0's. ... I was prepending my length of data ... Serialising my object into a memory stream ... correctly going past the 0's to find the start of the next packet. ...
    (microsoft.public.win32.programmer.networks)