Re: Another Beepcore-c Problem

David C Niemi wrote:
 > Sending multiple messages in one stream would require me to do my own
 > message numbering, which is a lot more work.  And if I do this 
switcheroo
 > per-message, it is just as much overhead (actually one packet more 
thanks
 > to the NUL) than if I just sent a RPY back.  So for now sending a RPY
 > seems the thing to do, and serves my purposes for the time being.

I think you're misunderstanding. What Bill is describing is this.

Right now, you have endpoint X sending a bunch of messages and getting 
no answers to endpoint Y.

X --- msg1 ---> Y
X --- msg2 ---> Y
X --- msg3 ---> Y
X --- msg4 ---> Y

BEEP doesn't work that way, because X doesn't know when to free the 
resources, so you'd normally go

X --- msg1 ---> Y
X <-- rpy1 ---- Y
X --- msg2 ---> Y
X <-- rpy2 ---- Y
X --- msg3 ---> Y
X <-- rpy3 ---- Y
X --- msg4 ---> Y
X <-- rpy4 ---- Y

If the RPY has no actual data in it, you could modify this slightly to go

X --- msg1 ---> Y
X <-- NUL  ---- Y
X --- msg2 ---> Y
X <-- NUL  ---- Y
X --- msg3 ---> Y
X <-- NUL  ---- Y
X --- msg4 ---> Y
X <-- NUL  ---- Y

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

That way, you don't need any acks coming back from Y at all. Of course, 
you eventually run out of answer numbers. (Mind, "eventually" at 2^32 is 
a pretty big number, depending on what each message represents.)

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

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

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

-- 
Darren New, San Diego CA USA (PST)
   I am in geosynchronous orbit, supported by
   a quantum photon exchange drive....


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