Re: Unnecessary Frame Fragmentation using beepcore-c?

Marshall Rose wrote:
 > well, beepcore-c needs work. it shouldn't get into silly window
 > syndrome.

I'll agree with this. However, I'm not sure how one would get around 
this without having some sort of timer in the core, and still allow 
fragmentation of frames. I think within the constraints of the design 
(memory allocation strictly limited to the size of the windows 
allocated, minimal copying of data bytes, no asynchronicity in the core) 
  it works fairly well.

Certainly if you want to aglomerate frames, or have a timer wait a short 
time until there's enough room on the channel, etc, then you could 
improve it. That was kind of the intention of having beepcore keep track 
of the "biggest recent window" and the "current send window". The core 
could fragment file sections to fit whichever was appropriate, or wait a 
brief time for them to become the same if there was some desire to align 
things.

 > what happens now, where beepcore-c allocates 4K to each
 > channel is just plain STUPID.

Uh, no, not really. Firstly, the 4K window isn't what's causing the 
problem. Secondly, the 4K window's actually specified in RFC3081 3.1.1. 
If the caller of beepcore wants to bump up the receiving window size, 
it's easy to do, but it's under control of the caller, since that'll 
obviously affect how much memory it uses. I don't think we'd want to use 
your algorithm, for example, on a port to a Z80-based controller that 
only *has* 64K of memory.

Beepcore.c is behaving exactly how 3.1.2 of RFC3081 says it should. 
There's three possibilities listed there, and beepcore.c takes the 
first. The second requires support from the OS in terms of a timer, and 
we didn't want to  put any OS dependencies into that part of the system. 
What's under discussion right now is a way of making the third option 
possible; it had been planned, but never got implemented due to time 
constraints.

It doesn't matter how big the window is. If you're sending some small 
frames and some frames as big as the receiver's maximum window, then the 
big frames will get fragmented by beepcore.c if there's only a partial 
window available. That's true whether the window is 4K or 400K.

What would you suggest would be the proper solution to Silly Window 
Syndrome?

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.




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