Re: Unnecessary Frame Fragmentation using beepcore-c?

David C Niemi <[email protected]> Wed, 17 Sep 2003 11:11:03 -0400 (EDT)
Newsgroups gmane.network.beep.beepcore.c.general
Message-ID <[email protected]>
On Tue, 16 Sep 2003, Marshall Rose wrote:
> could someone succinctly explain exactly what problem we're trying to
> solve. the beepcore-tcl implementation seems to work for several
> different apps without having this issue. perhaps there is some
> fundamental algorithm missing from beepcore-c that would obviate all of
> this...

As I started this whole discussion, I'll try to summarize it:

I have an application sending potentially large messages over a small
number of channels (at the moment just one).  The large messages are sent
rapidly (not waiting for per-frame acks) in max frame size (4K) chunks,
which tends to fill up the peer application's receive window.  At that
point the low-level (CBEEP.c) code tries to send whatever will fit into
the peer's receive window, which is usually a tiny fragment of one of the
4K frames.  Each time the receiver reads a small frame fragment, it frees
up a small part of its receive window, and another small frame is sent to
make use of the new space.  Thus the system settles into a pattern of
sending fragments for the entire large message, resulting in far more
frames sent and read by the receiver, hurting performance.

The proposed solution is to let the sending application detect the peer's
current receive window size, and to potentially hold off on sending the 4K
frames until at least that much space is available, based on
application-level logic.  I expect that a very small amount of delay by
the sender will permit getting into a pattern of full-sized frames and
thus result in better performance.  William Mills is looking into a clean 
way to expose the peer's window size at the application level.

-------------------------------------------------------
-- 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