Re: [Beepcore-c-users] Another Beepcore-c Problem

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

The protocol specifies that there will always be a response to
a MSG.

I don't think we are quite on the same page for the number wi
of messages needed for things.  If you wanted to deliver say 10 
1K messages that require no app level response you can:

-	send 10 MSG frames and get back 10 NUL frames.  20 messages.

-	get the reciever to *request* the data with a message and send
10 ANS and a NUL, so thats 1 MSG, 10 ANS, and a NUL, for a total 
12 messages.  If you needed to triger that from the sender side, you 
add on MSG/RPY to that.

ANS messages have an answer number which can be used to determine 
sequence/count and such.

The use of the NUL without ANS just to "ACK" the MSG was so that the
sender could know the profile on the other end in fact recieved the MSG.

Clearer?

-bill




On Thu, Mar 25, 2004 at 04:33:21PM -0500, David C Niemi wrote:
> On Thu, 25 Mar 2004, William J. Mills wrote:
> > If you don't need replies back, you can have the end getting all the
> > traffic send a MSG and send ANS frames back, as many as you want.  
> > Ending the stream with a NUL.
> 
> 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.
> 
> 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.  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.
> 
> 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.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
>