[Vortex] vortex_channel_update_incoming_buffer question

Francis Brosnan Blazquez francis at aspl.es
Tue Oct 14 20:22:56 CEST 2008


> Hello All!

Hi Mikhail!

> I have a question about code in vortex_channel_update_incoming_buffer
> where we decide to send SEQ frame or not:
> 
> vortex_channel.c, lines near 3365:
> 
> /* check we have filled half window size advertised */
> /*      if ((new_max_seq_no_accepted - channel->max_seq_no_accepted) < (window_size / 2)) { */
>         if ((consumed_seqno - (channel->max_seq_no_accepted - window_size)) < (window_size / 2)) {
> 
> Can anyone explain why we use window_size/2 magic number? I read
> discussion at
> http://drakken.dbc.mtview.ca.us/pipermail/beepwg/2006-January/001605.html about sending SEQ frames and now i don't understand why we use window_size/2.

Maybe this is the most obscure part of BEEP. Take a look on
http://www.rfc-editor.org/rfc/rfc3081.txt, page 4 as a starting point. 

This comes to avoid SWS and to improve interactions, by avoiding
excesive SEQ frame generation that could lead, for example, to window
reduction. Take a look at http://tools.ietf.org/rfc/rfc813.txt Funny
reading!

> I got a problem with this code then i change window_size. After some
> time of exchanging between listener and initiator one of them hangs
> up. It always happend at different time, so it is very hard to catch
> this bug. Now I know if i change 
> 
>         if ((consumed_seqno - (channel->max_seq_no_accepted -
> window_size)) < (window_size / 2)) {
> 
> to
> 
>         if ((consumed_seqno - (channel->max_seq_no_accepted - 4096)) <
> (4096 / 2)) {
> 
> all works fine, 

It works because it always sends a SEQ frame (assuming 64K of your
windows size). That is, it is more easy (32K / 2) be bigger than
consumed_seqno - (channel->max_seq_no_accepted - 32k) than 4K / 2.

Though this code works for you case (localhost or highly responsive
connection), it has the side effect that generates too many SEQ frames
and I think it could lead to several funny/undefined behaviors under the
general case...but more testing would be required to fully check/ensure
this..

> but i really don't understand why.

..me too (why it hangs?). I would check for latest log messages prefixed
with "SEQ FRAME" in both sides just after the hangs happens....

Cheers!

> WBR, Mikhail
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.



More information about the Vortex mailing list