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