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
