Re: Unnecessary Frame Fragmentation using beepcore-c?

On Tue, 16 Sep 2003, Darren New wrote:
> Darren New wrote:
> > AFAIK, the frames are broken up at the lowest level, just before being 
> > sent, yes.
> 
> Oh, BTW, frames are *not* stuck together, which is where the problem 
> comes from.
> 
> So if you have a 12K window, try sending 4K frames. If the first gets 
> broken, it may recover easier. The other possibility is to set up with a 
> 4K window, and then if you send a 2096-byte short frame, send another 
> 2000 bytes from the file before bumping back up to 4K records. Either of 
> these might help without changing the library itself.

I had made what I thought was an optimization that might be making things
worse.  I am sending a CPIO file header as my way of encapsulating
multisegment messages, and for large files I was sending the header first
by itself so that I could send the file on 4K-aligned blocks.  I can
reasonably expand the window size quite a bit, but it will never be as big
as some files might be, and as I understand it a larger window size will
not solve this problem by itself.

I don't really want to introduce extra over-the-network handshaking or
unnecessary latency here, but if the sender can do something to detect
that BEEP.c would fragment the frame it wants to send, it could reasonably
wait until the window is opened up to at least the size it wants to send.  
This would especially make sense if it would help the session to settle
into a pattern of 4K transfers.  Is there a straightforward and
inexpensive way of detecting the peer's current window size on the fly?

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf