Re: Unnecessary Frame Fragmentation using beepcore-c?

> 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.
    
great! get beepcore-c running on a z80 and then i'll agree that beepcore-c made
the right design decision...
    
the 4k number is the *minimum* guaranteed when a channel starts. it's
neither fixed nor an upper-bound...
    
    
> What would you suggest would be the proper solution to Silly Window 
> Syndrome?

timers in the internals, plus a flush call in the api...
    
if you look at the uIP code (a tiny tcp stack), that's probably a far
better model that what beepcore-c uses now: virtually no
os-dependencies, and a well-defined api saying how an application has to
behave in order for the state machine to run...
    
/mtr


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