[Vortex] BUG: Split greetings message aborts connection
jens at mooseyard.com
Tue Apr 22 23:40:46 CEST 2008
I'm making progress getting Vortex to send messages in 1k frames, for
better flow control. But I've run into a related problem that turns
out to be really messy, which I think I will work around inelegantly
because the fix keeps getting messier. But I'll describe the problem
here so an expert can work out what to do:
If the initial greetings message (or reply) on a connection is split
into multiple frames, Vortex ignores the "more" flag and tries to
parse it after it's read only the first frame. Of course the XML parse
fails, and Vortex drops the connection.
This will happen in the existing versions of Vortex if the greeting
message exceeds 4k bytes, because it then won't fit in the default
window. With the changes I'm working on, this actually causes the
Vortex regression tests to fail, because some of the greetings exceed
Here's my analysis. The root of the problem is
vortex_greetings_process, which makes a single call to
vortex_frame_get_next and then tries to parse the frame. That won't
work if the frame is not a complete message.
I've tried modifying vortex_greetings_process to use a loop, getting
frames and concatenating them as long as the "more" flag is set, and
then parsing the complete message. That works better, and allows the
regression tests to get about halfway through, but then a similar
greetings-parse failure occurs.
The reason for _this_ failure is that __vortex_connection_new actually
calls vortex_greetings_client_process in a loop. If the first call
fails, it waits for more data to arrive on the socket, then calls it
again. I think this happens because the socket is non-blocking and
reads might fail due to insufficient data? But what's going wrong is
that the first call to vortex_greetings_client_process reads the first
frame of the message, and then fails ... and then the second call to
vortex_greetings_client_process only reads the second frame. Then it
tries to parse that second frame and dies.
I think this solution to this is to move the wait-and-retry logic down
into vortex_greetings_process, so it can still assemble all the frames
in one call. But I have to say, the code in __vortex_connection_new is
so nasty looking that I'm afraid to touch it -- it's a very long and
complex function, and it's full of evil goto statements.
So my workaround is going to be to modify my initial changes that
break messages into 1k frames, to _not_ do that on channel 0. That way
the greeting messages will stay in one piece and not trigger the
problems with parsing them. However, this really should be fixed at
some point because
(a) if anyone adds enough profiles to grow the greetings beyond 4k, it
will inevitably break Vortex; and
(b) other BEEP implementations are likely to break frames into small
chunks, since it's recommended in the RFC, so Vortex will run into
this issue when connecting to those clients.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080422/7dd599ab/attachment.bin
More information about the Vortex