469,313 Members | 2,597 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,313 developers. It's quick & easy.

NetworkStream & inconsistent protocols

Hi,
I have been working with what i believe is, an poorly designed
client/protocol, and this is causing me no end of headaches determining the
end of a 'fragment'. The header of each fragment ends in a constant fasion
(single line consisting of a carriage return) however the payload afterwards
containing xml fragment does not end in a consistent fasion, this would be
fine if the stream was closed and the protocol was '1 shot' and you could
detect this but this isn't the case with all the fragments(consistency is
nowhere to be found in this system!) and often the client expects a return
fragment back down the same stream (in the same transaction).
The protocol is very http in style.

the transaction is (in one stream):
(client) (server) (client)
(server)
header header header
header
/r/n --> /r/n -->
--> /r/n
xml fragment xmlfragment xmlfragment
xmlfragment

It is detection of the end of the xmlfragment which holds no consistency and
the client holds the connection open awaiting the return fragment but the
server sits on the readLine waiting for a response from the client. Only
when the client closes the connection because it doesn't return a fragment
will the code continue (with an exception) but by then the transaction is
then spoilt as the client has closed off.

The other read methods on in the StreamReader class exhibit the same
behaviour. I am reluctant to use intrenal timers or other workarounds, and
the problem does not lie with the classes and methods but in the protocol.

Has anyone come accross a similar situation with other 'protocols' and
found/not found any workarounds?

I can supply some samples/code if people think they will help but at this
stage don't feel they wil add anything.

thanks in advance for your help.

Mike




Nov 15 '05 #1
2 1443
mike b <te**@mike.here> wrote:
I have been working with what i believe is, an poorly designed
client/protocol, and this is causing me no end of headaches determining the
end of a 'fragment'. The header of each fragment ends in a constant fasion
(single line consisting of a carriage return) however the payload afterwards
containing xml fragment does not end in a consistent fasion, this would be
fine if the stream was closed and the protocol was '1 shot' and you could
detect this but this isn't the case with all the fragments(consistency is
nowhere to be found in this system!) and often the client expects a return
fragment back down the same stream (in the same transaction).
The protocol is very http in style.


<snip>

HTTP in style except without the Content-Length :(

If these are meant to be proper XML fragments, could you not just read
until you've got a full XML fragment? In other words, if you get:

<foo>
<bar>
baz
</bar>
</foo>

then as soon as you see </foo> you know you're finished, don't you? Or
could there be another foo element?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
mike b <te**@mike.here> wrote:
I have been working with what i believe is, an poorly designed
client/protocol, and this is causing me no end of headaches determining the end of a 'fragment'. The header of each fragment ends in a constant fasion (single line consisting of a carriage return) however the payload afterwards containing xml fragment does not end in a consistent fasion, this would be fine if the stream was closed and the protocol was '1 shot' and you could detect this but this isn't the case with all the fragments(consistency is nowhere to be found in this system!) and often the client expects a return fragment back down the same stream (in the same transaction).
The protocol is very http in style.


<snip>

HTTP in style except without the Content-Length :(

If these are meant to be proper XML fragments, could you not just read
until you've got a full XML fragment? In other words, if you get:

<foo>
<bar>
baz
</bar>
</foo>

then as soon as you see </foo> you know you're finished, don't you? Or
could there be another foo element?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


yeah the content the Content-Length would be such a boon

I honestly cannot believe I didn't think of the XML checking method ... :(

many thanks for the prompt reply and fresh idea!

thanks
Mike
Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by 0to60 | last post: by
27 posts views Thread by Daniel Vallstrom | last post: by
3 posts views Thread by codeman | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.