Re: Unnecessary Frame Fragmentation using beepcore-c?

This has to do with the frame size and window size.  The data payload
will be reduced by the amount of the frame headers, which is the 
missing info to make the payload sizes make more sense I think.

My suspicion is that the frame and window sizes are perhaps
similar....  try cranking up the window size and see what that does.

-bill


On Wed, Sep 10, 2003 at 12:55:47PM -0400, David C Niemi wrote:
> 
> I have an application that sends potentially large files using beepcore-c.  
> It sometimes manages to send them in CHUNKSIZE (4K) frames, but other 
> times it sends 4K frames and when they get to the other side they are 
> badly fragmented.  This seems rather inefficient and at times downright 
> inconvenient; I'd like to be able to count on at least very small frames 
> making it intact.
> 
> I am using the latest CVS version.
> 
> Does anyone know where or why this fragmentation would be introduced, and 
> whether it might be remedied somehow?  Here is an example of what is 
> happening:
> 
> Sender:
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> ...
> Calling send_chunk for 4096 bytes, final=0, msgno=5.
> Calling send_chunk for 3977 bytes, final=1, msgno=5.
> 
> Receiver:
> SEND frame_available: type=M number=5 answer=-1 more=* size=2788
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=172
> SEND frame_available: type=M number=5 answer=-1 more=* size=2616
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=344
> SEND frame_available: type=M number=5 answer=-1 more=* size=2444
> SEND frame_available: type=M number=5 answer=-1 more=* size=1136
> SEND frame_available: type=M number=5 answer=-1 more=* size=516
> ...
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=* size=3568
> SEND frame_available: type=M number=5 answer=-1 more=* size=528
> SEND frame_available: type=M number=5 answer=-1 more=. size=3449
> 
> It seems almost as though the frame sizes are random, although it does 
> settle into a rhythm of 3568 + 528 byte frames about halfway through a 1 
> MB file.  The entire file does always make it intact, eventually.
> 
> -------------------------------------------------------
> -- 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
> _______________________________________________
> Beepcore-c-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users


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