[standards-jig] JNG Ramblings.
iain.shigeoka at messaginglogic.com
Wed Aug 14 03:15:23 UTC 2002
On 8/12/02 7:37 PM, "Mike Lin" <mikelin at MIT.EDU> wrote:
>> The seven least significant bits of the first byte in the header defines the
>> total message length EXCEPT if the most significant bit is set. In that
>> case, the seven least significant bits indicate the size (in octets) of the
>> integer that will describe the packet size. This gives you up to a 127 byte
>> integer to describe the packet size (I don't see that _ever_ being
>> practically exceeded).
> It might not be a terrible idea (high praise from me :-), although it
> would approximately double the number of states in a protocol framer
> state machine, and complicate the way the headers are decoded. I'll
> consider it, but I personally am very fond of having all the information
> you need sitting in a CPU register.
:) Thanks for the praise. I completely agree with the reasoning for
register length data. However, I think in this case, portability and
extensibility is better:
A) The current trend seems to be abstracting the machine. Java and C# are
looking like the future and both define data types independent of underlying
platforms. It is hard to tell if the field will converge onto Intel or
diverge again with the emergence of ARM (PocketPC, Palm) and more appliance
B) Changing the header lengths once you set them is going to be really
painful. I always like binary because it gives a chance for FSM and with
that usually follows hardware implementations. Witness IP and the
extraordinary lack of speed in switching to IPv6.
C) The majority of users are on Win32 Intel. The majority of servers will
be 64 bit. Sometime in the not too distant future, Wintel is going to move
to 64 bit on the desktop. So the pain of B is going to hit sooner rather
D) The extensibility puts to bed any complaints about running out of room.
With the scheme I proposed you could probably assign a type to every atom on
the planet if you so choose (that's a total guess... Let's see 2^(127*8) and
what's Avogadro's number and the weight of the earth...)
> the singleton server core. But in any case I don't think it is fair for
> either of us (lacking the firsthand experience) to say what causes the
> first scalability bottleneck in the server.
Agreed. I would actually guess that if you could move the processing into
hardware its a noop. They're making XML routers now so maybe its already a
> The alternative, which is to do asynchrony in-band like BEEP, I think is
> too much work. TCP is designed to provide these services, so I'm in
> favor of using it.
No arguments here. I don't have the expertise to offer an opinion. I think
field trials are needed. :)
>> PS - partly unrelated, but if we're going binary, I wonder if it wouldn't be
>> prudent to integrate addressing into the headers. Perhaps some address
>> dictionary so that you could establish a per session mapping of routing ID
>> numbers to particular Jabber nodes/resources. That way routing and
>> processing are completely separate activities and the router doesn't have to
>> understand XML.
> Yes, one thing we've been toying with is where we now have "Unspecified"
> and "XML" payload types, let's roll in a few specific things like
> "Destination Address GUID" as payload types, thus greatly reducing the
> need for router XML parsing. There are a lot of open questions related
> to doing this properly, however; for the purposes of addressing, it
> seems like it would be useful to have XML extensibility, particularly if
> we are going to be doing things like store-and-forward. So while this is
> an idea that may be worth looking into, there are open questions that
> I'm not going to consider in the proof-of-concept phase.
Yeah. Have you looked at the oceanstore stuff at UC Berkeley? (Sorry, no
immediate URL on hard.) I was actually thinking in that direction with
binary addressing. Basically, create an address space big enough that you
can address _everything_. Thus, no real need to be extensible because
everything is addressed. Then its just a matter of routing, organizing, and
assigning human readable names... :) Pie in the sky stuff though.
> Lastly, as a more general comment, although I've been coming on strong,
> and have been testy at points, I'm really glad that we're finally having
> this argument - it's a discussion we've needed to have for a long time.
I am too. I'm going to pour some more gas on the fire in my next post. :)
More information about the Standards