From beepwg-bounces@dbc.mtview.ca.us Tue Jan 03 14:08:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtrWO-0007io-FF for beep-archive@megatron.ietf.org; Tue, 03 Jan 2006 14:08:39 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13711 for ; Tue, 3 Jan 2006 14:07:20 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k03J4xJY000936; Tue, 3 Jan 2006 11:05:01 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k03J4s6U000933 for ; Tue, 3 Jan 2006 11:04:57 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1EtrSX-00072K-00; Tue, 03 Jan 2006 20:04:37 +0100 Subject: RE: [BEEPwg] Lightweight RPC over BEEP From: Francis Brosnan Blazquez To: Jonathan Perret In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Tue, 03 Jan 2006 20:04:45 +0100 Message-Id: <1136315085.4235.20.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1EtrSX-00072K-00*yENIM8M8y/I* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k03J4s6U000933 cc: BEEPwg X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA13711 El lun, 02-01-2006 a las 11:09 +0000, Jonathan Perret escribi=F3: > Francis, Hi Jonathan, Peter, >=20 > Sorry if I do not read you correctly, but it does not seem to me that > DNS-SD matches your description above : > - "centralized" : DNS-SD fits very well on top of the totally > decentralized Multicast-DNS. In fact DNS-SD+Multicast-DNS =3D Apple's > "Bonjour" (ex-"Rendezvous") stack, widely acclaimed as a neat > standards-based solution to the service discovery problem. > - "same host" : the point of DNS-SD is that you're not looking for a > host but a service - the location of that service may change from > minute to minute (and DNS-SD APIs generally provide alerts to client > software to let them know about updates to service topology). Of > course nothing prevents you from restricting your search to the local > host if that's what you need. A bit of reading before sending my response have showed that DNS-SD/mDNS are likely to be the especification we were looking for. I'm impressed about the zeroconf working group whole definition, reusing existing/standard technologies, and the amount of projects/people that are implementing/interested on it!=20 >=20 > > But, at the client side, to perform desktop IPC between=20 > > applications to compose bigger ones running on top of Af-Arch=20 > > we have realized that, already being attached to a BEEP=20 > > engine, why don't use that engine to connect to other=20 > > components thourgh an lightweigh RPC rather than going to use=20 > > other IPC? >=20 > That's a fine idea but as you seem to have recognized already, the > choice of the BEEP protocol is orthogonal to the choice of a discovery > mechanism. >=20 > Surely you know about Apple's Xgrid ? Probably the most > widely-deployed BEEP application these days (or ever, for that > matter !). It uses BEEP for transport and DNS-SD for discovery. >=20 No!, I didn't. I've been reading Bonjour and Xgrind specs and they are lovely works.=20 Jonathan, Peter,=20 Thanks for your replies! > Cheers, > --Jonathan --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 04:02:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuR10-0003Ok-88 for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 04:02:36 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14183 for ; Thu, 5 Jan 2006 04:01:16 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k058xYt1026382; Thu, 5 Jan 2006 00:59:36 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k058xTvq026379 for ; Thu, 5 Jan 2006 00:59:32 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1EuQxe-0005YU-00; Thu, 05 Jan 2006 09:59:06 +0100 From: Francis Brosnan Blazquez To: BEEPwg Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Thu, 05 Jan 2006 09:59:25 +0100 Message-Id: <1136451565.22303.9.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1EuQxe-0005YU-00*/u6vvbGLACo* Subject: [BEEPwg] Some toughts about BEEP+DNS-SD/mDNS X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit Hi there, Some thoughts about BEEP+DNS-SD/mDNS (and maybe without link-local): Stuart have pointed me to a new book he has written about zero conf technologies and some comments on that area: --- One of the problems we have right now is that there's almost too much Bonjour/Zeroconf information on the web, and that can be a bit daunting to a newcomer. Because of this I wrote an O'Reilly book to gather all the relevant information together into one concise volume. It just came out the week before Christmas. There's a link at the web site. Please feel free to forward this to the list if you feel it's appropriate. --- Thinking about how Apple have mixed DNS-SD/mDNS with BEEP to produce Xgrid (at least, maybe more products are over there) shows that they are impressive partners for building peer-to-peer networked protocols. This joining solves (as the Xgrind team have realized) nearly every problem found on moderm networked applications: the power of the peer-to-peer transaction supported by BEEP and the easyness to find other computer and services as we were running on top of AppleTalk but doing so on TCP/IP! >From the conversation on this mailling list with Jonathan and Peter that have permited to me to know such technologies (thanks you guys) one could easily think this is a key area to promote as a fundation for a new family of networked applications. Cheers! -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 04:07:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuR5O-0005BV-I1 for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 04:07:07 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14594 for ; Thu, 5 Jan 2006 04:05:49 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k0594DKU026496; Thu, 5 Jan 2006 01:04:14 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k0594BJO026491 for ; Thu, 5 Jan 2006 01:04:12 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1EuR2B-0005gC-00; Thu, 05 Jan 2006 10:03:47 +0100 From: Francis Brosnan Blazquez To: Paul Lacy , BEEPwg Content-Type: text/plain Organization: Advanced Software Production Line, S.L. Date: Thu, 05 Jan 2006 10:04:06 +0100 Message-Id: <1136451846.22303.15.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1EuR2B-0005gC-00*afm.4I.A04.* Subject: [BEEPwg] Some SEQ frame questions X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit Hi there, Now some technical question about BEEP and SEQ frames: Paul [1] have reported a bug on the Vortex Library bugzilla showing that SEQ frame are still not really supported. While making some code to finish this area in a basic manner I've runned into the following questions: 1) If a client peer wants to reduce/increase the window size for a given channel, one might deduce that it should issue a SEQ message with the desired new window size. This will produce that the local window size will be configured with the new window size and a SEQ frame is set to the remote peer. It this right? But, what if the remote side doesn't agree on changing requested value for the new window size? How it is used the ackno value for the SEQ frame received? 2) Because the purpose of the SEQ frame, it is stated that they should have greater priority over same messages on the same channel, but, this will break the principle "every message send on the same channel is sent sequentially". If there are 10 frames waiting to be send and a SEQ frame is issued then these messages are freezed until the SEQ frame is sent? Does this means that over the same channel "normal" frames are sent sequentially but, there another queue with higher priority to send SEQ frames generated? Does SEQ frames increase frame octec counting (seqno, size) or the message counting (msgno) for a channel when the are sent and received? 3) It is easy to understand that any change required to the window size for a given channel will required to produce a SEQ frame to be sent, but if the window size doesn't change: It is required to keep on sending SEQ frames notifying current status of the channel buffer? 4) What could happen if BEEP peer just ignore SEQ frames or don't generate SEQ frames? Any comment would be appreciated! Cheers! [1] http://dolphin.aspl.es/cgi-bin/bugzilla/show_bug.cgi?id=277 -- Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 09:08:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuVnE-0001yI-OU for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 09:08:41 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17812 for ; Thu, 5 Jan 2006 09:07:24 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05E48ih030585; Thu, 5 Jan 2006 06:04:26 -0800 Received: from hotmail.com (bay115-dav16.bay115.hotmail.com [65.54.250.88]) k05E47Mr030582 for ; Thu, 5 Jan 2006 06:04:07 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Jan 2006 06:04:02 -0800 Message-ID: Received: from 24.99.144.45 by BAY115-DAV16.phx.gbl with DAV; Thu, 05 Jan 2006 14:03:52 +0000 X-Originating-IP: [24.99.144.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Thu, 05 Jan 2006 09:03:51 -0500 Subject: Re: [BEEPwg] Some SEQ frame questions From: Peter Hall To: Francis Brosnan Blazquez , Paul Lacy , BEEPwg Message-ID: In-Reply-To: <1136451846.22303.15.camel@vulcan.aspl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jan 2006 14:04:02.0230 (UTC) FILETIME=[E1AF4D60:01C61200] X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit Francis See my comments inline > From: Francis Brosnan Blazquez > Organization: Advanced Software Production Line, S.L. > Date: Thu, 05 Jan 2006 10:04:06 +0100 > To: Paul Lacy , BEEPwg > Subject: [BEEPwg] Some SEQ frame questions > > Hi there, > > Now some technical question about BEEP and SEQ frames: > > Paul [1] have reported a bug on the Vortex Library bugzilla showing > that SEQ frame are still not really supported. While making some code > to finish this area in a basic manner I've runned into the following > questions: > > 1) If a client peer wants to reduce/increase the window size for a > given channel, one might deduce that it should issue a SEQ message > with the desired new window size. Correct. But RFC3081 has an implementation guideline that says "For example, Section 4.2.2.16 of RFC1122 [5] indicates that a "receiver SHOULD NOT shrink the window, " > > This will produce that the local window size will be configured > with the new window size and a SEQ frame is set to the remote > peer. It this right? > > But, what if the remote side doesn't agree on changing requested > value for the new window size? > I cannot find an answer to this one. Read the 3 bullet points in rfc3081 3.1.2 Sending Messages 1) segment messages 2) delay until the window is large enough 3) report error to application > How it is used the ackno value for the SEQ frame received? There is nothing. > > 2) Because the purpose of the SEQ frame, it is stated that they should > have greater priority over same messages on the same channel, but, > this will break the principle "every message send on the same > channel is sent sequentially". > > If there are 10 frames waiting to be send and a SEQ frame is issued > then these messages are freezed until the SEQ frame is sent? > > Does this means that over the same channel "normal" frames are sent > sequentially but, there another queue with higher priority to send > SEQ frames generated? > > Does SEQ frames increase frame octec counting (seqno, size) or the > message counting (msgno) for a channel when the are sent and > received? No changes to the counts > > 3) It is easy to understand that any change required to the window > size for a given channel will required to produce a SEQ frame to be > sent, but if the window size doesn't change: > > It is required to keep on sending SEQ frames notifying current > status of the channel buffer? No need to keep sending them > > 4) What could happen if BEEP peer just ignore SEQ frames or don't > generate SEQ frames? This is what I have done. I'll accept the SEQ frame but I never send a SEQ frame. When I send a message I'll split the message into whatever the remote peer SEQ requested. When I receive a segmented message I'll cache the data until I received the final piece. Only after I've received the complete message do I hand it back to the application. > > Any comment would be appreciated! > > Cheers! > > [1] http://dolphin.aspl.es/cgi-bin/bugzilla/show_bug.cgi?id=277 > > > -- > Francis Brosnan Blazquez > Advanced Software Production Line, S.L. > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 11:10:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuXhS-0006ZI-7c for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 11:10:51 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02752 for ; Thu, 5 Jan 2006 11:09:34 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05G7orf031803; Thu, 5 Jan 2006 08:07:52 -0800 Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) k05G7m97031800 for ; Thu, 5 Jan 2006 08:07:48 -0800 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 05 Jan 2006 11:07:41 -0500 id 0061C015.43BD444D.000023BC In-Reply-To: <1136451846.22303.15.camel@vulcan.aspl> References: <1136451846.22303.15.camel@vulcan.aspl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 11:07:39 -0500 To: Francis Brosnan Blazquez X-Mailer: Apple Mail (2.746.2) cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On Jan 5, 2006, at 4:04 AM, Francis Brosnan Blazquez wrote: > Hi there, > > Now some technical question about BEEP and SEQ frames: > > Paul [1] have reported a bug on the Vortex Library bugzilla showing > that SEQ frame are still not really supported. While making some code > to finish this area in a basic manner I've runned into the following > questions: One thing that may not be clear here: supporting SEQ frames is REQUIRED if you want your BEEP implementation to interoperate with other BEEP implementations. There is some flexibility in how the implementation actually handles them, but it must honor incoming SEQ frames and emit SEQ frames. I have, in the past, worked with a BEEP implementation that didn't support SEQ frames, and it did work fairly well with itself (this was beepy, prior to its switch to using twisted), but it had no hope of working with any other BEEP implementation. > 1) If a client peer wants to reduce/increase the window size for a > given channel, one might deduce that it should issue a SEQ message > with the desired new window size. Um, yes, but I'm not sure you are seeing what the SEQ frame is saying. It isn't saying that "oh, I accept messages up to 4k", it is saying "I have 4k available *right now*". That is, the SEQ frame isn't a policy announcement, it is a statement about what the peer is willing to accept at that moment. > This will produce that the local window size will be configured > with the new window size and a SEQ frame is set to the remote > peer. It this right? I couldn't parse this question. > But, what if the remote side doesn't agree on changing requested > value for the new window size? There is no room for disagreement. It is up to the remote side to not send more data than the local side is willing to accept. > How it is used the ackno value for the SEQ frame received? I can't remember anything specific. In general, it is probably used as a sanity check. > 2) Because the purpose of the SEQ frame, it is stated that they should > have greater priority over same messages on the same channel, but, > this will break the principle "every message send on the same > channel is sent sequentially". What is being said is that the SEQ frames should be given priority in the sequence. > If there are 10 frames waiting to be send and a SEQ frame is issued > then these messages are freezed until the SEQ frame is sent? Could be. > Does this means that over the same channel "normal" frames are sent > sequentially but, there another queue with higher priority to send > SEQ frames generated? That is one way to implement it, but not the only way. > Does SEQ frames increase frame octec counting (seqno, size) or the > message counting (msgno) for a channel when the are sent and > received? > 3) It is easy to understand that any change required to the window > size for a given channel will required to produce a SEQ frame to be > sent, but if the window size doesn't change: > > It is required to keep on sending SEQ frames notifying current > status of the channel buffer? Yes! > 4) What could happen if BEEP peer just ignore SEQ frames or don't > generate SEQ frames? When I was implementing my own BEEP implementation (the Net::BEEP::Lite perl module), I found SEQ to be the hardest thing to grasp, so I'm not particularly surprised when implementations skip it. However, SEQ is not an optional part of BEEP over TCP. What SEQ is doing, essentially, is saying: "hey! I can receive N octets on this channel!". If you are a sender, it is required that you do not send any more than N octets on that channel, possibly causing the message to fragment. (note that the octet count doesn't include the frame header and \r\nEND bit). If you, as the sender, actually send more than N octets, then you can expect the remote end to either discard data or to freak out and end the session. So, this is why ignoring incoming SEQs isn't a good idea. If you are receiving data, yet not emitting SEQs, then the remote sender will stop sending you data past the default SEQ of 4096 octets. Essentially, your channel will quickly stall. So this is why it is a good idea to *send* SEQs. Now, as I stated at the top of this message, if both sender and receiver are ignoring SEQs, then the protocol will work, which is why an implementation can get away with not implementing SEQ support: they self-interoperate. However, the implementation will NOT interoperate with a different BEEP implementation that *does* implement SEQ. -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 11:31:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuY13-0004xT-9u for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 11:31:05 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05309 for ; Thu, 5 Jan 2006 11:29:49 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05GQb5M031958; Thu, 5 Jan 2006 08:26:38 -0800 Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) k05GQaPh031955 for ; Thu, 5 Jan 2006 08:26:36 -0800 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 05 Jan 2006 11:26:33 -0500 id 0061C015.43BD48B9.00002A27 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 11:26:32 -0500 To: Peter Hall X-Mailer: Apple Mail (2.746.2) cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On Jan 5, 2006, at 9:03 AM, Peter Hall wrote: >> 3) It is easy to understand that any change required to the window >> size for a given channel will required to produce a SEQ frame to be >> sent, but if the window size doesn't change: >> >> It is required to keep on sending SEQ frames notifying current >> status of the channel buffer? > > No need to keep sending them Um, no. I think you've misunderstood how SEQ works. It is true that you do not have to send a new SEQ frame after every received frame (although you could). You DO need to send one either before the original buffer size is exhausted, or immediately afterwards. What the SEQ frame says is: on this channel, you may send me N octets. It isn't saying "break every message in to N octet frames". >> >> 4) What could happen if BEEP peer just ignore SEQ frames or don't >> generate SEQ frames? > > This is what I have done. I'll accept the SEQ frame but I never > send a SEQ > frame. When I send a message I'll split the message into whatever > the remote > peer SEQ requested. Have you actually interoperated with, say, beepcore-j? -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 12:50:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZFo-00041v-90 for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 12:50:25 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17070 for ; Thu, 5 Jan 2006 12:49:08 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05Hk6PC032701; Thu, 5 Jan 2006 09:46:06 -0800 Received: from hotmail.com (bay115-dav4.bay115.hotmail.com [65.54.250.76]) k05Hk56u032698 for ; Thu, 5 Jan 2006 09:46:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Jan 2006 09:45:59 -0800 Message-ID: Received: from 63.174.67.2 by BAY115-DAV4.phx.gbl with DAV; Thu, 05 Jan 2006 17:45:58 +0000 X-Originating-IP: [63.174.67.2] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Thu, 05 Jan 2006 12:45:57 -0500 Subject: Re: [BEEPwg] Some SEQ frame questions From: Peter Hall To: David Blacka Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 05 Jan 2006 17:45:59.0062 (UTC) FILETIME=[E3229B60:01C6121F] X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05Hk56u032698 cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA17070 I'm not sure if I've tried against beepcore. I'm trying to findout for su= re I've personally not done it. The way I read it was that the SEQ message says don't send me frames larg= er X. is that wrong? What I think your saying is don=B9t send a message with a total payload l= arger that X. in other words send me either 1 message no larger than X or send = me many continuation messages but not to exceed X. Why send multiple SEQ messages if it's not changed? Isn't that just wasti= ng bandwidth? As it happens my application a reliable syslog server/client don't need t= o send more than 4K so may be I've just not had to deal with that problem. saying that it does work against over vendors servers/clients. The only reason I implemented what I did with the SEQ message with becaus= e other vendors applications sent it. Because I don=B9t send a SEQ it just means I'll accept the default 4K. Peter > From: David Blacka > Date: Thu, 5 Jan 2006 11:26:32 -0500 > To: Peter Hall > Cc: Francis Brosnan Blazquez , Paul Lacy > , BEEPwg > Subject: Re: [BEEPwg] Some SEQ frame questions >=20 >=20 > On Jan 5, 2006, at 9:03 AM, Peter Hall wrote: >=20 >>> 3) It is easy to understand that any change required to the window >>> size for a given channel will required to produce a SEQ frame to be >>> sent, but if the window size doesn't change: >>>=20 >>> It is required to keep on sending SEQ frames notifying current >>> status of the channel buffer? >>=20 >> No need to keep sending them >=20 > Um, no. I think you've misunderstood how SEQ works. >=20 > It is true that you do not have to send a new SEQ frame after every > received frame (although you could). You DO need to send one either > before the original buffer size is exhausted, or immediately afterwards. >=20 > What the SEQ frame says is: on this channel, you may send me N > octets. It isn't saying "break every message in to N octet frames". >=20 >=20 >>>=20 >>> 4) What could happen if BEEP peer just ignore SEQ frames or don't >>> generate SEQ frames? >>=20 >> This is what I have done. I'll accept the SEQ frame but I never >> send a SEQ >> frame. When I send a message I'll split the message into whatever >> the remote >> peer SEQ requested. >=20 > Have you actually interoperated with, say, beepcore-j? >=20 > -- > David Blacka > Sr. Engineer VeriSign Applied Research >=20 >=20 >=20 >=20 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 13:48:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua9s-00042y-Et for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 13:48:20 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25558 for ; Thu, 5 Jan 2006 13:47:03 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05IjNr4000676; Thu, 5 Jan 2006 10:45:24 -0800 Received: from dolphin.aspl.es (134.Red-80-34-198.staticIP.rima-tde.net [80.34.198.134])k05IjK0a000673 for ; Thu, 5 Jan 2006 10:45:21 -0800 Received: from elaine ([10.0.0.4] helo=vulcan.aspl) by dolphin.aspl.es with esmtp (ASPL Mail Server XP#1) id 1Eua6f-0003wZ-00; Thu, 05 Jan 2006 19:45:01 +0100 Subject: Re: [BEEPwg] Some SEQ frame questions From: Francis Brosnan Blazquez To: David Blacka In-Reply-To: References: <1136451846.22303.15.camel@vulcan.aspl> Content-Type: text/plain; charset=ISO-8859-15 Organization: Advanced Software Production Line, S.L. Date: Thu, 05 Jan 2006 19:45:23 +0100 Message-Id: <1136486724.28670.53.camel@vulcan.aspl> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Scanner: exiscan *1Eua6f-0003wZ-00*zYn6ILZ6TtI* X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05IjK0a000673 cc: BEEPwg X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA25558 El jue, 05-01-2006 a las 11:07 -0500, David Blacka escribi=F3: Hi David, really helpful comments!,=20 As you have clearly described, it seems that the SEQ frames is a kind of ACK datagram commonly used on many underlaying protocols that allow peers to perform flow control, so:=20 1) It is up to each peer to announce the SEQ frame for its own channel window (maybe should be called "buffer") sizes and ... 2) Remote peer receiving SEQ frames MUST follow that information to avoid getting annoyed (aka flooded) its partner peer. But, what makes me get confused is that RFC3081 doesn't say something like: "BEEP peers receiving a SEQ frame should take its ackno value to check it with current seqno over the selected channel and limit its next sending to the window value received, including stopping from sending more data if it is overflow, until a next SEQ frame is received". Then I read your comment: --- > How it is used the ackno value for the SEQ frame received? I can't remember anything specific. In general, it is probably used =20 as a sanity check. --- Well, or SEQ frames are windows rolling on mech reporting to the remote peer how many data could hold at a particular time until get it into the application level or it is something else!. In case that SEQ frames are buffer size ack mechanism, ackno value should play a very important role on this issue. >From your next two comments, could you be more specific?: 1)--- > 2) Because the purpose of the SEQ frame, it is stated that they should > have greater priority over same messages on the same channel, but, > this will break the principle "every message send on the same > channel is sent sequentially". What is being said is that the SEQ frames should be given priority in =20 the sequence. 1)--- 2)--- > Does this means that over the same channel "normal" frames are sent > sequentially but, there another queue with higher priority to send > SEQ frames generated? That is one way to implement it, but not the only way. 2)--- Great reply David,=20 --=20 Francis Brosnan Blazquez Advanced Software Production Line, S.L. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 13:51:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaCn-0004dg-6r for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 13:51:21 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25837 for ; Thu, 5 Jan 2006 13:50:04 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05ImTHC000713; Thu, 5 Jan 2006 10:48:29 -0800 Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) k05Iln93000697 for ; Thu, 5 Jan 2006 10:47:49 -0800 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k05IkVZk012025; Thu, 5 Jan 2006 10:46:31 -0800 (PST) Received: from [17.221.41.131] (dkramer1.apple.com [17.221.41.131]) by relay6.apple.com (Apple SCV relay) with ESMTP id B69843B2; Thu, 5 Jan 2006 10:46:30 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9F7EF577-6F98-4334-B93A-C71E7630B33D@apple.com> From: David Kramer Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 10:46:29 -0800 To: Peter Hall X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05Iln93000697 cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA25837 > The way I read it was that the SEQ message says don't send me =20 > frames larger > X. is that wrong? Yes, that is incorrect. I think I can make this clearer for everyone with an example. When a channel opens, the receiving window size for both peer A and =20 peer B is 4096 bytes. If peer A sends a frame with a payload of size =20 1024 to peer B, then peer B's receiving window size shrinks to 3072. =20 If peer A sends another frame with payload size 1024 to peer B, then =20 peer B's receiving window size shrinks further to 2048. If peer B =20 never sends a SEQ frame, and peer A continues to send frames, then =20 peer B's receiving window size will eventually reach zero. At this =20 point, if peer A sends any data to peer B, this is a protocol =20 violation and peer B immediately terminates the session. What you need to understand is that the window shrinks with every =20 byte received. The SEQ doesn't say "this is the maximum per-frame =20 size I'll accept whenever", it says "this is the total number of =20 bytes you may send me until I send you a new SEQ frame extending the =20 window." For a window size of 4096 it could by 4096 1-byte frames, =20 or 1 4096-byte frame, or some combination in between. Note that it is required for a BEEP stack to deal with SEQ frames in =20 the middle of a message. For instance, if peer A wants to sends a =20 message that is 5000 bytes long, and peer B has a receiving window =20 size of of 4096, then peer A could send a frame no larger than 4096 =20 bytes. At this point, peer A still has 4 bytes left to send, which =20 it cannot do until it receives a new SEQ frame from peer B extending =20 with window by at least 4 bytes. Therefore peer B needs to be able =20 to send SEQ frames in the middle of receiving the message, and peer A =20 needs to be able to receive SEQ frames in the middle of sending the =20 message. This might be easier to understand if you consider what the reasoning =20 behind the SEQ frame is. It is a mechanism for flow control. It is =20 a way for peer B to say, I have only allocated a certain amount of =20 memory for receiving frames, so don't send me more than that until I =20 say it's okay. If peer B wants to receive a message larger than the =20 window size, then peer B will have to send SEQ frame, which it will =20 do once it has allocated additional space to receive it. Suppose peer A wants to send a large file to peer B, which peer B =20 will save to disk. However, peer B doesn't have very much memory =20 available. Therefore, peer B will advertise a small (4K) window, and =20 every time the window gets close to being filled, it will write out =20 all of the data from memory onto disk, and then grow the window back =20 to 4K. This way peer B never requires more than a 4K buffer for =20 holding frame payloads but it can still receive a very large file. Another tricky aspect of SEQ handling is that each channel of each =20 peer has it's own independent receiving window size. Thus there are =20 two window sizes associated with each channel. Each peer needs to =20 know the size of the window being advertised by the other, while at =20 the same time keeping track of the window it has advertised to the =20 other. The former is important so that the peer doesn't send more =20 data than the other can handle, while the latter is important so that =20 the peer knows when it needs to send a SEQ to the other to re-extend =20 the window. Another point which was made earlier is that the window may never be =20 shrunk by a SEQ frame. The window is only, and always, shrunk as the =20 result of receiving data. The sending peer needs to keep track of =20 how many bytes it sends and subtract that from the last advertised =20 window size, so that it never sends more data than can fit in the =20 window. Likewise, the receiving peer needs to keep track of how many =20 bytes it receives and subtract that from the last window size it =20 advertised, so that it knows when the window is full and needs to be =20 re-extended. -David Kramer On Jan 5, 2006, at 9:45 AM, Peter Hall wrote: > > I'm not sure if I've tried against beepcore. I'm trying to findout =20 > for sure > I've personally not done it. > > The way I read it was that the SEQ message says don't send me =20 > frames larger > X. is that wrong? > > What I think your saying is don=92t send a message with a total =20 > payload larger > that X. in other words send me either 1 message no larger than X or =20 > send me > many continuation messages but not to exceed X. > > Why send multiple SEQ messages if it's not changed? Isn't that just =20 > wasting > bandwidth? > > As it happens my application a reliable syslog server/client don't =20 > need to > send more than 4K so may be I've just not had to deal with that =20 > problem. > saying that it does work against over vendors servers/clients. > > The only reason I implemented what I did with the SEQ message with =20 > because > other vendors applications sent it. > > Because I don=92t send a SEQ it just means I'll accept the default 4K. > > Peter > > >> From: David Blacka >> Date: Thu, 5 Jan 2006 11:26:32 -0500 >> To: Peter Hall >> Cc: Francis Brosnan Blazquez , Paul Lacy >> , BEEPwg >> Subject: Re: [BEEPwg] Some SEQ frame questions >> >> >> On Jan 5, 2006, at 9:03 AM, Peter Hall wrote: >> >>>> 3) It is easy to understand that any change required to the window >>>> size for a given channel will required to produce a SEQ frame =20 >>>> to be >>>> sent, but if the window size doesn't change: >>>> >>>> It is required to keep on sending SEQ frames notifying current >>>> status of the channel buffer? >>> >>> No need to keep sending them >> >> Um, no. I think you've misunderstood how SEQ works. >> >> It is true that you do not have to send a new SEQ frame after every >> received frame (although you could). You DO need to send one either >> before the original buffer size is exhausted, or immediately =20 >> afterwards. >> >> What the SEQ frame says is: on this channel, you may send me N >> octets. It isn't saying "break every message in to N octet frames". >> >> >>>> >>>> 4) What could happen if BEEP peer just ignore SEQ frames or don't >>>> generate SEQ frames? >>> >>> This is what I have done. I'll accept the SEQ frame but I never >>> send a SEQ >>> frame. When I send a message I'll split the message into whatever >>> the remote >>> peer SEQ requested. >> >> Have you actually interoperated with, say, beepcore-j? >> >> -- >> David Blacka >> Sr. Engineer VeriSign Applied Research >> >> >> >> > > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:02:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaNf-00089t-Im for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:02:35 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27673 for ; Thu, 5 Jan 2006 14:01:18 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05IxSoB000800; Thu, 5 Jan 2006 10:59:28 -0800 Received: from mail.sarbserve.com (mail.sarbserve.com [24.244.171.76]) k05IxRbR000797 for ; Thu, 5 Jan 2006 10:59:27 -0800 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) k05IwgPW016193; Thu, 5 Jan 2006 10:58:43 -0800 In-Reply-To: <9F7EF577-6F98-4334-B93A-C71E7630B33D@apple.com> References: <9F7EF577-6F98-4334-B93A-C71E7630B33D@apple.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 10:58:46 -0800 To: David Kramer X-Mailer: Apple Mail (2.746.2) cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit > This might be easier to understand if you consider what the > reasoning behind the SEQ frame is. It is a mechanism for flow > control. It is a way for peer B to say, I have only allocated a > certain amount of memory for receiving frames, so don't send me > more than that until I say it's okay. If peer B wants to receive a > message larger than the window size, then peer B will have to send > SEQ frame, which it will do once it has allocated additional space > to receive it. i agree with absolutely everything in your email as to how SEQ works and why; however, i want to add one thing to the above paragraph: let's answer the question: "why?". after any tuning, if you could open only one channel for data exchange, then you wouldn't have SEQ frames in BEEP. they wouldn't be needed. however, because you are allowed to open multiple simultaneous channels for data exchange, you can run into a problem commonly referred to as "head of line". this is where one channel monopolizes all of the underlying transport capacity by sending something really big, and the other channels get blocked behind that data. so, what SEQ allows a BEEP peer to do is coordinate use of the available bandwidth by the channels being multiplexed over a single TCP connection. for example, the BEEP API you use may allow you to associate a priority with each channel (or each message sent by a channel), then when the implementation of that API sees that it's able to send a frame over the TCP connection, it can determine which channel should get to use the bandwidth. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:08:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaTQ-0004Gc-1W for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:08:32 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28376 for ; Thu, 5 Jan 2006 14:07:15 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05J4OO5000859; Thu, 5 Jan 2006 11:04:25 -0800 Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) k05J4OkS000856 for ; Thu, 5 Jan 2006 11:04:24 -0800 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 05 Jan 2006 14:04:20 -0500 id 0061C01B.43BD6DB4.00005F20 In-Reply-To: <1136486724.28670.53.camel@vulcan.aspl> References: <1136451846.22303.15.camel@vulcan.aspl> <1136486724.28670.53.camel@vulcan.aspl> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <77CB599A-7F07-4628-A7B3-BD83FD09D0AE@verisignlabs.com> From: David Blacka Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 14:04:18 -0500 To: Francis Brosnan Blazquez X-Mailer: Apple Mail (2.746.2) X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05J4OkS000856 cc: BEEPwg X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA28376 On Jan 5, 2006, at 1:45 PM, Francis Brosnan Blazquez wrote: > El jue, 05-01-2006 a las 11:07 -0500, David Blacka escribi=F3: > > Hi David, really helpful comments!, > > As you have clearly described, it seems that the SEQ frames is a =20 > kind of > ACK datagram commonly used on many underlaying protocols that allow > peers to perform flow control, so: > > 1) It is up to each peer to announce the SEQ frame for its own channel > window (maybe should be called "buffer") sizes and ... > > 2) Remote peer receiving SEQ frames MUST follow that information to > avoid getting annoyed (aka flooded) its partner peer. > > But, what makes me get confused is that RFC3081 doesn't say something > like: "BEEP peers receiving a SEQ frame should take its ackno value to > check it with current seqno over the selected channel and limit its =20 > next > sending to the window value received, including stopping from sending > more data if it is overflow, until a next SEQ frame is received". > > Then I read your comment: > > --- >> How it is used the ackno value for the SEQ frame received? > > I can't remember anything specific. In general, it is probably used > as a sanity check. > --- Yeah, I spaced for a moment. The ackno value is, indeed, critical. =20 In my head I was thinking that that field was called "seqno" and =20 ackno was some other useless field. This is what you get from not =20 looking stuff up! -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:19:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaeF-0001eJ-TD for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:19:44 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29941 for ; Thu, 5 Jan 2006 14:18:27 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05JGliY000970; Thu, 5 Jan 2006 11:16:49 -0800 Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) k05JGiFX000967 for ; Thu, 5 Jan 2006 11:16:44 -0800 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Thu, 05 Jan 2006 14:16:40 -0500 id 0061C036.43BD7098.00006486 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: From: David Blacka Subject: Re: [BEEPwg] Some SEQ frame questions Date: Thu, 5 Jan 2006 14:16:39 -0500 To: Peter Hall X-Mailer: Apple Mail (2.746.2) X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05JGiFX000967 cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA29941 On Jan 5, 2006, at 12:45 PM, Peter Hall wrote: > > I'm not sure if I've tried against beepcore. I'm trying to findout =20 > for sure > I've personally not done it. > > The way I read it was that the SEQ message says don't send me =20 > frames larger > X. is that wrong? SEQ is advertising a current buffer size for a channel for that =20 moment in time (or more precisely, for a particular sequence =20 number). It isn't talking about frames specifically. > What I think your saying is don=92t send a message with a total =20 > payload larger > that X. in other words send me either 1 message no larger than X or =20 > send me > many continuation messages but not to exceed X. It is saying that you can send up to X octets without another SEQ, =20 regardless of the message/frame breakdown. > Why send multiple SEQ messages if it's not changed? Isn't that just =20 > wasting > bandwidth? SEQ is implementing flow control, so think of it as an ACK. > As it happens my application a reliable syslog server/client don't =20 > need to > send more than 4K so may be I've just not had to deal with that =20 > problem. > saying that it does work against over vendors servers/clients. Well, you would be able to send *only* 4k on a given channel. Well, =20 reliably in any case. Also keep in mind that you will be able to =20 perfectly interoperate with yourself. So if both peers are using =20 your BEEP implementation, I wouldn't expect a problem. > The only reason I implemented what I did with the SEQ message with =20 > because > other vendors applications sent it. Well, they have to. > Because I don=92t send a SEQ it just means I'll accept the default 4K. It means you will only accept 4k total on each channel. Here is what BEEP implementations need to do with respect to SEQ: Senders must track on a per channel basis how many octets they are =20 allowed to send. So, initially, on channel creation, this may be set =20 to 4096. Now lets say you send 200 octets in two frames. =20 Immediately, the sender updates this number to 3896, and notes that =20 it has sent a total of 200 octets. Now lets say that the sender has =20 received a SEQ frame that says "SEQ 1 100 4096". This means: "after =20 receiving octet 100 on channel 1, I can receive 4096 more octets of =20 payload". So the sender gets to update its number to 3996. It is =20 now allowed to send at most 3996 octets before getting another SEQ =20 frame. Note that the ackno field is critical here. Receivers need to have a mechanism for knowing when they must send a =20 SEQ frame to prevent the channel from stalling. In general, they do =20 this by mirroring the calculation that the sender is doing (i.e., =20 subtract on receipt of data, resetting when sending a SEQ), but this =20 isn't the only way to do it. Also note that like sequence numbers, SEQ frames operate on a per-=20 channel and per-direction basis. -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:36:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuauE-0000dP-4M for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:36:14 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02022 for ; Thu, 5 Jan 2006 14:34:57 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05JWLhn001128; Thu, 5 Jan 2006 11:32:21 -0800 Received: from hotmail.com (bay115-dav17.bay115.hotmail.com [65.54.250.89]) k05JWJ4K001125 for ; Thu, 5 Jan 2006 11:32:19 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Jan 2006 11:32:16 -0800 Message-ID: Received: from 24.99.144.45 by BAY115-DAV17.phx.gbl with DAV; Thu, 05 Jan 2006 19:32:16 +0000 X-Originating-IP: [24.99.144.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Thu, 05 Jan 2006 14:32:11 -0500 Subject: Re: [BEEPwg] Some SEQ frame questions From: Peter Hall To: David Blacka Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jan 2006 19:32:16.0695 (UTC) FILETIME=[BC802C70:01C6122E] cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit I've just had confirmation that a vender has used beepcore-java and it works fine with my implemention. P > From: David Blacka > Date: Thu, 5 Jan 2006 11:26:32 -0500 > To: Peter Hall > Cc: Francis Brosnan Blazquez , Paul Lacy > , BEEPwg > Subject: Re: [BEEPwg] Some SEQ frame questions > > > On Jan 5, 2006, at 9:03 AM, Peter Hall wrote: > >>> 3) It is easy to understand that any change required to the window >>> size for a given channel will required to produce a SEQ frame to be >>> sent, but if the window size doesn't change: >>> >>> It is required to keep on sending SEQ frames notifying current >>> status of the channel buffer? >> >> No need to keep sending them > > Um, no. I think you've misunderstood how SEQ works. > > It is true that you do not have to send a new SEQ frame after every > received frame (although you could). You DO need to send one either > before the original buffer size is exhausted, or immediately afterwards. > > What the SEQ frame says is: on this channel, you may send me N > octets. It isn't saying "break every message in to N octet frames". > > >>> >>> 4) What could happen if BEEP peer just ignore SEQ frames or don't >>> generate SEQ frames? >> >> This is what I have done. I'll accept the SEQ frame but I never >> send a SEQ >> frame. When I send a message I'll split the message into whatever >> the remote >> peer SEQ requested. > > Have you actually interoperated with, say, beepcore-j? > > -- > David Blacka > Sr. Engineer VeriSign Applied Research > > > > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:54:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EubBr-0002YB-HE for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:54:28 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04535 for ; Thu, 5 Jan 2006 14:53:10 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05JpcaC001302; Thu, 5 Jan 2006 11:51:39 -0800 Received: from hotmail.com (bay115-dav12.bay115.hotmail.com [65.54.250.84]) k05JpaQ9001299 for ; Thu, 5 Jan 2006 11:51:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Jan 2006 11:51:28 -0800 Message-ID: Received: from 24.99.144.45 by BAY115-DAV12.phx.gbl with DAV; Thu, 05 Jan 2006 19:51:28 +0000 X-Originating-IP: [24.99.144.45] X-Originating-Email: [whiz100@hotmail.com] X-Sender: whiz100@hotmail.com User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Thu, 05 Jan 2006 14:51:27 -0500 Subject: Re: [BEEPwg] Some SEQ frame questions From: Peter Hall To: David Blacka Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 05 Jan 2006 19:51:28.0709 (UTC) FILETIME=[6B278F50:01C61231] X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05JpaQ9001299 cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA04535 That's better, now I understand what it is trying to do. I never did it i= n the first place because I could get my head around it. I'll make the changes. Thanks Peter > From: David Blacka > Date: Thu, 5 Jan 2006 14:16:39 -0500 > To: Peter Hall > Cc: Francis Brosnan Blazquez , Paul Lacy > , BEEPwg > Subject: Re: [BEEPwg] Some SEQ frame questions >=20 >=20 > On Jan 5, 2006, at 12:45 PM, Peter Hall wrote: >=20 >>=20 >> I'm not sure if I've tried against beepcore. I'm trying to findout >> for sure >> I've personally not done it. >>=20 >> The way I read it was that the SEQ message says don't send me >> frames larger >> X. is that wrong? >=20 > SEQ is advertising a current buffer size for a channel for that > moment in time (or more precisely, for a particular sequence > number). It isn't talking about frames specifically. >=20 >> What I think your saying is don=B9t send a message with a total >> payload larger >> that X. in other words send me either 1 message no larger than X or >> send me >> many continuation messages but not to exceed X. >=20 > It is saying that you can send up to X octets without another SEQ, > regardless of the message/frame breakdown. >=20 >> Why send multiple SEQ messages if it's not changed? Isn't that just >> wasting >> bandwidth? >=20 > SEQ is implementing flow control, so think of it as an ACK. >=20 >> As it happens my application a reliable syslog server/client don't >> need to >> send more than 4K so may be I've just not had to deal with that >> problem. >> saying that it does work against over vendors servers/clients. >=20 > Well, you would be able to send *only* 4k on a given channel. Well, > reliably in any case. Also keep in mind that you will be able to > perfectly interoperate with yourself. So if both peers are using > your BEEP implementation, I wouldn't expect a problem. >=20 >> The only reason I implemented what I did with the SEQ message with >> because >> other vendors applications sent it. >=20 > Well, they have to. >=20 >> Because I don=B9t send a SEQ it just means I'll accept the default 4K. >=20 > It means you will only accept 4k total on each channel. >=20 > Here is what BEEP implementations need to do with respect to SEQ: >=20 > Senders must track on a per channel basis how many octets they are > allowed to send. So, initially, on channel creation, this may be set > to 4096. Now lets say you send 200 octets in two frames. > Immediately, the sender updates this number to 3896, and notes that > it has sent a total of 200 octets. Now lets say that the sender has > received a SEQ frame that says "SEQ 1 100 4096". This means: "after > receiving octet 100 on channel 1, I can receive 4096 more octets of > payload". So the sender gets to update its number to 3996. It is > now allowed to send at most 3996 octets before getting another SEQ > frame. Note that the ackno field is critical here. >=20 > Receivers need to have a mechanism for knowing when they must send a > SEQ frame to prevent the channel from stalling. In general, they do > this by mirroring the calculation that the sender is doing (i.e., > subtract on receipt of data, resetting when sending a SEQ), but this > isn't the only way to do it. >=20 > Also note that like sequence numbers, SEQ frames operate on a per- > channel and per-direction basis. >=20 > -- > David Blacka > Sr. Engineer VeriSign Applied Research >=20 >=20 >=20 >=20 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Thu Jan 05 14:59:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EubH5-00036N-OS for beep-archive@megatron.ietf.org; Thu, 05 Jan 2006 14:59:52 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04977 for ; Thu, 5 Jan 2006 14:58:35 -0500 (EST) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id k05Jv69T001365; Thu, 5 Jan 2006 11:57:06 -0800 Received: from bulk.resource.org (bulk.resource.org [192.101.98.10]) k05Jv3WG001362 for ; Thu, 5 Jan 2006 11:57:04 -0800 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by bulk.resource.org (8.12.2/8.12.2) with ESMTP id k05JuxOQ025033 for ; Thu, 5 Jan 2006 11:57:00 -0800 (PST) Received: by wproxy.gmail.com with SMTP id 67so3309709wri for ; Thu, 05 Jan 2006 11:54:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CGIlJCu6jZ/fLrw36awiOlowTrLQgTVtNyrSy9WBEIsACMZqXIv/391pFqQbrCOPlQthOwrpPnmJY9nFHIkLncUoUZCdi6q9HEp4YBM15kOu9MeaPUlUqNzXSxu0PO6X+FRuMw3wiL2Hel/GvssafBJQBSxewAcjCDE0WNqXruI= Received: by 10.65.95.5 with SMTP id x5mr1555234qbl; Thu, 05 Jan 2006 11:54:57 -0800 (PST) Received: by 10.65.97.8 with HTTP; Thu, 5 Jan 2006 11:54:57 -0800 (PST) Message-ID: Date: Thu, 5 Jan 2006 11:54:57 -0800 From: Gabe Wachob To: Peter Hall Subject: Re: [BEEPwg] Some SEQ frame questions In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id k05Jv3WG001362 cc: BEEPwg cc: Paul Lacy X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 8bit Just a reminder that for folks implementing beep libraries/code and would like to talk with similar folks, there is the beepbuilders email list and sourceforge project (the sf project never did much, but the email list is active): http://beepbuilders.sf.net If there is interest in developing the sf project (test cases, harnesses, etc), please let me know - I'd be even willing to hand over the project to someone else with a more vested interest at this point. -Gabe On 1/5/06, Peter Hall wrote: > I've just had confirmation that a vender has used beepcore-java and it works > fine with my implemention. > > P > > > From: David Blacka > > Date: Thu, 5 Jan 2006 11:26:32 -0500 > > To: Peter Hall > > Cc: Francis Brosnan Blazquez , Paul Lacy > > , BEEPwg > > Subject: Re: [BEEPwg] Some SEQ frame questions > > > > > > On Jan 5, 2006, at 9:03 AM, Peter Hall wrote: > > > >>> 3) It is easy to understand that any change required to the window > >>> size for a given channel will required to produce a SEQ frame to be > >>> sent, but if the window size doesn't change: > >>> > >>> It is required to keep on sending SEQ frames notifying current > >>> status of the channel buffer? > >> > >> No need to keep sending them > > > > Um, no. I think you've misunderstood how SEQ works. > > > > It is true that you do not have to send a new SEQ frame after every > > received frame (although you could). You DO need to send one either > > before the original buffer size is exhausted, or immediately afterwards. > > > > What the SEQ frame says is: on this channel, you may send me N > > octets. It isn't saying "break every message in to N octet frames". > > > > > >>> > >>> 4) What could happen if BEEP peer just ignore SEQ frames or don't > >>> generate SEQ frames? > >> > >> This is what I have done. I'll accept the SEQ frame but I never > >> send a SEQ > >> frame. When I send a message I'll split the message into whatever > >> the remote > >> peer SEQ requested. > > > > Have you actually interoperated with, say, beepcore-j? > > > > -- > > David Blacka > > Sr. Engineer VeriSign Applied Research > > > > > > > > > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg > -- Gabe Wachob / gwachob@wachob.com / http://www.wachob.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg