Re: Unnecessary Frame Fragmentation using beepcore-c?

David C Niemi wrote:
> Indeed, being able to determine what one's peer's window size is Right Now
> would do the trick.  An alternative would be to have more flexibility
> built into send_chunk(), being able to tell it NEVER_FRAGMENT vs
> AVOID_FRAGMENT vs SEND_IMMEDIATELY (the current behavior and presumably 
> the default).  Although I suppose BEEP.c wouldn't much enjoy implementing 
> the latter, as it doesn't want to block waiting for the window to open up 
> wider; perhaps instead it could return a EWOULDFRAGMENT error in that 
> case.

Making it not fragment frames wouldn't be too hard. There's a routine 
that looks for the next frame to send, and you'd just have it say "Nope, 
not this one" if you have the flag set. I can't say I'm 100% sure what 
"NEVER_FRAGMENT" vs "AVOID_FRAGMENT" difference is.

I'd be leary of adding flags like this, tho, as they'd clearly make for 
interop problems. Something a bit more robust in a wider range of cases 
(like, not talking to BEEP.c) would be better. But then you'd have to 
start dealing with timers and things like that, since I doubt you'd want 
to completely stop sending if the receiver reduced its window size, for 
example, and thus never got back to where you thought it should be.

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