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

[William J. M. <wm...@es...>]

I downloaded the source, and I think I have the build 
running on freebsd correctly.  I'll think about adding 
either a method to get what we think the peer window size 
is, or modifying bpc_set_window_size to take teh additional
special value -2...

-bill


On Tue, Sep 16, 2003 at 08:55:49PM -0400, David C Niemi wrote:
> On Tue, 16 Sep 2003, Darren New wrote:
> > William J. Mills wrote:
> > > bpc_set_window_size will return the recieve windows size, but
> > > not the peer's.  It returns the plocal size with an arg of -1
> > > and takes no action.  Perhaps we should add a -2 to get the remote
> > > size....
> > 
> > I'd suggest checking the documentation to see what I called it. I 
> > actually did think it through, and generally I think you want to be able 
> > to tell both how big the window is Right Now, and how big the window has 
> > been in recent times. I.e., you want to be able to get an idea of what 
> > the argument to the peer's bpc_set_window_size is, altho that's 
> > naturally harder than just looking at what we know right now.
> 
> 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.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
>