Re: [Beepcore-c-users] Unnecessary Frame Fragmentation using beepcore-c?

[David C N. <dc...@ad...>]

On Tue, 16 Sep 2003, Darren New wrote:
> 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'm not sure either -- I was thinking that some applications might want to 
insist on their frame not being fragmented, while others might simply want 
to suggest as a hint that it would be better not to fragement it.  A moot 
point.

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

I think I must agree.  Certainly introducing timers into BEEP.c is not 
something to take lightly.

I am quite happy with William's plan to let the sending application find
out the receiver's window size (as perceived by the low-level code on the
sender).  That way, whatever intelligence needed to tune the application
can be kept out of BEEP.c, at least if this all works as I anticipate.  
If it doesn't work as hoped (e.g. if window size tends to change between
the query and the send_chunk() operation), perhaps there could be a
version or flag of send_chunk() that returns an error if the receiving
window is too small to send the frame intact (leaving it up to the sending
application what to do about it).

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------