I think the confusion here is the ambiguous terminology. In the UDP header, what is called the request id is really a message id if one considers that a message contains one or more requests. In the request header what is called the message id is really the request id, ie the ID of this specific get/set/add/replace/incr/decr/delete request.
I¹d really like to see the terminology rationalized, so that UDP headers refer to message ids and request headers refer to request ids. But in either case, they are not the same. We discussed this a bit at the facebook hackathon. I forget what the consensus was, but I think the consensus was that there were already too many places where message == request in existing code. As far as a different magic byte. I don¹t see it as a real win. The magic-byte is per ³request² and a packet may have multiple requests. The idea was just to make it easy to identify request boundaries in packet traces and to allow a protocol processor to assert that it must be looking at a request boundary when executing error-recovery logic. There is only on UDP header per UDP packet, so the magic byte there wouldn¹t do anything there other than take up space. The other fields already provide enough information for the receiver to determine whether the packet is expected or not. On 12/17/07 11:34 AM, "Aaron Stone" <[EMAIL PROTECTED]> wrote: > On Mon, Dec 17, 2007, Dustin Sallings <[EMAIL PROTECTED]> said: > >> > >> > On Dec 16, 2007, at 19:26, Aaron Stone wrote: >> > >>> >> Do we want to add 32 bits to the binary protocol for UDP sequencing? >>> >> Has >>> >> this been discussed before? If so, please point me in the direction of >>> >> such a thread in the mailing list archives! >> > >> > >> > No, UDP support seems to be the minimal wrapping around the >> > underlying protocol to provide sequencing. Not sure if I can point >> > you to archives, but the intention should be somewhat clear. >> > >> > The purpose of a UDP based protocol would be to provide a >> > connectionless form of the TCP based protocol with less client and >> > server overhead. >> > >> > When you think about it that way, you're just implementing some of >> > the parts that the transport doesn't give you, so it makes sense to >> > not combine them in such a way that provides redundancy with your >> > transport. If you're optimistic, you have less overhead in general. >> > > > Well, ok, but the only thing that the UDP header provides that the binary > protocol does not now provide directly is sequence numbers for > reassembling a large SET / GET. > > Here's an idea: we have a different magic byte that indicates that the > common header is four bytes longer, and we use that magic byte for UDP > traffic? > > Aaron > >
