[Vortex] BUG: Split greetings message aborts connection

[Jens Alfke]

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  
1k.

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.

—Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080422/7dd599ab/attachment.bin