Re: Unnecessary Frame Fragmentation using beepcore-c?

Marshall Rose wrote:

 > the 4k number is the *minimum* guaranteed when a channel starts. it's
 > neither fixed nor an upper-bound...


Nore is it in beepcore-c. It's just that the core itself doesn't modify 
it unless the application requests that.

 >> What would you suggest would be the proper solution to Silly Window 
Syndrome?
 >
 >
 > timers in the internals, plus a flush call in the api...


That's pretty much what we're discussing how to do, yes. We're figuring 
out what needs to be exposed so the application (i.e., wrapper) can 
delay, and then determine if the buffer is empty, so you'd get a kind of 
flush API. But that's outside the core of beepcore-c, and up to the 
wrapper to implement. We're discussing what parts of the core have to be 
exposed to the wrapper to let the wrapper do such a thing.

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


Then the other possibility is to put a "don't fragment" flag in beepcore 
such that if the leading frame to be sent won't fit in the window, the 
core will just return without sending anything, which is basically what 
uIP does. Sounds like an interop nightmare when you start getting 
complex protocols with multiple channels and limited buffer space to not 
deadlock, but if you're in control of the source code for both sides, it 
could be a win, sure. That too should be easy to implement.

If you put this flag in, you wouldn't need timers, you'd just wait for 
the remote side to trigger the sending by sending you a SEQ with a 
sufficiently big window. uIP only uses the timers to trigger 
retransmits, not to control anything to do with fragmentation.

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