Re: Another Beepcore-c Problem

On Thu, 25 Mar 2004, Darren New wrote:
> However, an even more efficient way of doing this is to go
> 
> X <--- msg  --- Y
> X ---- ans1 --> Y
> X ---- ans2 --> Y
> X ---- ans3 --> Y
>    ...
> X ---- NUL  --> Y

OK, so once in a while a NUL would be sent which could trigger a fresh MSG
to allow a fresh set of ANSes.  I guess that would work, as long as there
can be many frames in an answer that have the same answer number, but it
sounds like a rather strange way of using the protocol.


>  > However, the reason I don't want to do RPYs is that (per the end-to-end
>  > principle) I want to acknowledge things at a higher application 
> layer, far
>  > above BEEP, so the BEEP-level RPY is not really needed.
> 
> If you want to do any sort of acks at all, they have to come back 
> *somewhere*. The end-to-end principle doesn't mean you shouldn't do 
> low-level acks. It means that low-level acks aren't sufficient for 
> high-level acks. If Y never sends a frame back to X, then you're not 
> doing end-to-end principle either. :-)

Y eventually sends a frame back, based on the MSG going up to the high
level app and generating a high level reply which is carried in a separate
BEEP message.  There's no practical way to make this a reply to the 
original message number because it could come from another machine 
entirely (due to load-balancing).


>  >  Is the
>  > requirement to do RPYs or ANSes from BEEP spec itself, or from the
>  > Beepcore-C implementation?  It would have made sense to me to have a
>  > message type that did not expect a reply at the BEEP level.
> 
>  From the spec. And no, it wouldn't really, because then you couldn't 
> reuse message numbers and you'd eventually run out.

I'd like to just forget message numbers once the final frame is sent.  I 
think.  Just like Answer Numbers are presumably forgotten right away once 
all the frames in the answer are sent.


>  > Anyway, the message numbering does seem to have been the issue at hand,
>  > and I am taking care of it now.  Thanks to both William and Darren for
>  > pointing it out.
> 
> Glad I could remember what that message meant. ;-)

By the way, I was also wondering about this comment in CBEEP.c.  Do you 
think it is still a problem?

  /* BUGGY! THIS ASSUMES NO 2^32-1 WRAPPING! Use "long long" here? */
static void find_best_seq_to_send(struct session * s) {
  struct channel * best; /* Best */
  struct channel * test; /* test */ 
  long b_size;
  long t_size;
...


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




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click