NetworkStream & inconsistent protocols

  • Thread starter Thread starter mike b
  • Start date Start date
M

mike b

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
 
mike b said:
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.
Click to expand...

<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 said:
<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?
Click to expand...

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
 
Back
Top