[Vortex] BUG(?): Increasing channel window size breaks connection

Jens Alfke jens at mooseyard.com
Sat Apr 19 02:09:53 CEST 2008


I've been trying larger values for channel->window_size, by changing  
the initial values in vortex_channel_empty_new( ).
A value of 16384 helps my throughput problems somewhat, but not enough.

Values larger than 16384, however, cause the connection to abort as  
soon as the high-volume data transfer begins. Strangely, each side  
accuses the other of closing the socket, as shown below. Is growing  
the window triggering a bug in Vortex? Has it ever been tested with  
larger window sizes?

At this point I'm going into a mild panic. This functionality is  
critical for my app, and it isn't working in common scenarios. If I  
have to give up on BEEP for this, it'll take me weeks of work to  
implement a second TCP connection with some custom protocol for  
sending the data chunks.

—Jens

With a window size of 32768, here's what's logged on the reader end:

16:01:48.047| vortex-reader: something to read
16:01:48.049| vortex-frame-factory: line read from underlying  
transport: 'RPY 7 0 . 0 32768
'
16:01:48.049| vortex-frame-factory: from='get-next' allocating a new  
frame id=29
16:01:48.049| vortex-frame-factory: (ok message) received a frame  
fragment (expected: 32773 read: 16365 remaining: 16408), storing into  
this connection id=5
16:01:48.049| vortex-reader: something to read
16:01:48.049| vortex-frame-factory: received more data after a frame  
fragment, previous read isn't still complete
16:01:48.049| vortex-frame-factory: remaining bytes to be read: 16408
16:01:48.049| vortex-frame-factory: bytes already read: 16365
16:01:48.049| vortex-tls: SSL_read returned that isn't ready to read:  
retrying
16:01:48.049| vortex-frame-factory: deallocating frame id=29
16:01:48.049| CRITICAL: Vortex+vortex-frame-factory: remote peer have  
closed connection while reading the rest of the frame having received  
part of it
16:01:48.049| vortex-connection: flagging the connection as non- 
connected
16:01:48.049| vortex-connection: closing connection id=5 to  
10.0.1.100:60506

While on the sending end:

16:01:47.889| Vortex: vortex-reader: something to read
16:01:47.890| WARNING*** : Vortex+vortex-tls: SSL_read  
(SSL_ERROR_SYSCALL)
16:01:47.890| WARNING*** : CRITICAL: Vortex+vortex-frame-factory:  
unable to read a line, error was: Connection reset by peer
16:01:47.890| WARNING*** : CRITICAL: Vortex+vortex-frame-factory: an  
error have ocurred while reading socket
16:01:47.890| Vortex: vortex-connection: flagging the connection as  
non-connected
16:01:47.890| BEEP: BPError #8: The connection unexpectedly closed:  
client have disconnected without closing session
16:01:47.891| Vortex: vortex-connection: closing connection id=3 to  
10.0.1.180:60506
16:01:47.891| Vortex: vortex-connection: closing session id=3 and set  
to be not connected

-------------- 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/20080418/9ea4e7c4/attachment.bin 


More information about the Vortex mailing list