<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18 Apr '08, at 5:09 PM, Jens Alfke wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Cochin; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">I've been trying larger values for channel->window_size, by changing the initial values in vortex_channel_empty_new( ).<br></span></blockquote></div><br><div>Now that I've read more about how windows work (thanks to Francis's helpful article at beepcore.org) I see that this was the wrong way to do it. The window size of a new channel is implicitly 4096, so for one peer to start with a different value will confuse the other. Instead, the window size has to be changed by sending a SEQ frame to notify the other peer.</div><div><br></div><div>I'm adding a vortex_channel_set_window_size function. In doing so, I noticed that the documentation for the existing getter function seems to be incorrect:</div><div><br></div><div><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">/**&nbsp;</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* @brief Returns actual channel window size.</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;*</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* Maximum window size accepted by remote peer. This is the number of</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* bytes that the remote peer is willing to accept until a new SEQ</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* frame is set.</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;*&nbsp;</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* @param channel the channel to operate on.</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;*&nbsp;</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* @return the window size or -1 if fails</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;*/</font></div><div><font class="Apple-style-span" color="#000000">int &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; vortex_channel_get_window_size (VortexChannel * channel)</font></div></blockquote><br></div><div>The implementation of window_size shows that it's used as the maximum number of bytes that the _local_ peer will accept, not the remote peer. Also, the value is the _current_ window size, not the maximum (I don't think there is a maximum, other than INT_MAX.)</div><div><br></div><div>I suggest changing the description to:</div><div><br></div><div><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">&nbsp;* Current window size used for receiving data on this channel. This is the number of</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* bytes that the local peer is willing to accept at once, before sending a new SEQ</font></div><div><font class="Apple-style-span" color="#000000">&nbsp;* frame.</font></div></blockquote><br></div><div>I'll submit a proposed patch for the new API call once I've finished testing it; probably by tomorrow morning (California time).</div><div><br></div><div>óJens</div></body></html>