[jdev] parsing xml (xmpp) with ruby
Justin Karneges
justin-keyword-jabber.093179 at affinix.com
Mon Sep 29 11:24:04 CDT 2008
On Monday 29 September 2008 00:29:18 Michal 'vorner' Vaner wrote:
> Hello
>
> On Mon, Sep 29, 2008 at 09:19:17AM +0200, Remko Tronçon wrote:
> > > I tried to create my own XMPP parser/library (for, ehm, educational
> > > purposes). I never come across this issue. As far as I understand it, I
> > > get proceed, but no more binary data.
> >
> > You mean you don't get binary data when you did a read() of
> > <proceed/>? You can't rely on that on a TCP connection.
>
> I could rely on that if the server sent them only as a response to _my_
> binary data. If it is this:
>
> S: <proceed/>
> C: Binary greeting
> S: Binary response
>
> Then everything is OK, because I can get ready for binary before I send
> my binary part. I'm not sure it is this way, but whenever I looked on a
> TCP dump or expected this behaviour, it always worked this way.
>
> Of course, If this could happen too:
> S: <proceed/>
> S: Some binary data
> C: Binary response
>
> Then I would be out of luck and couldn't expect it to come out as two
> separate reads.
>
> I expect the proceed is ment as server telling me he is ready for _my_
> binary data. It won't send me any binary data unless I do it first.
True, for TLS this is mostly an academic problem. In the TLS protocol, the
client speaks first, so you shouldn't receive TLS data from the server until
the client has sent his data. You'd probably have to do something like this:
<starttls/>[tls handshake] (client assumes starttls will succeed)
<proceed/>[tls handshake reply]
Tony Finch has suggested behavior like this for round-trip optimization.
-Justin
More information about the JDev
mailing list