[JDEV] Connectivity and streaming.
tcharron at ductape.net
Wed Oct 13 11:00:10 CDT 1999
Quoting Scott Robinson <quad at jabber.org>:
> This post is being originated from the fact that there are many able coders
> on this list, but none can become involved because Jer leaves many details
> for later. The coding architecture of Jabber is still very centralized. The
> recent message-level routing discussion has given me much faith in The
> Jabber Team, and I believe that we can work from what we currently have
> developing a full v0.7 protocol spec.
I agree, in part. Anyone is welcome to join libs-dev and start chatting, but
I have seen '0' traffic on that list.. Nadda, zlich, zip. I guess I don't
understand your complaint here? It it that you think Jer is idea hording?
> Currently, on docs.jabber.org, Jer has posted a very sketchy example of an
> XML streaming system. While this works for many systems, and it especially
> flows well with our "coherent XML document" paradigm, I would like to place
> the following on the table: we cannot assume we'll be running on a reliable
> socket medium.
This I CAN agree with. I truely wish we had a more solid document on exactly
what the XML Streams will look like, etc..
> a) client and transport
> Between the client and transport, the connection requirements are unknown
> as well as the data. This is exactly what the Jabber paradigm is in that we
> want to create transports which can connect to ANY IM-esque protocol in
> existance as well as ones to come. This means we cannot place any
> requirements upon the data coming into our transports.
Err, I don't think there are any limitations. Heck, the
transport<=>Etherx<=>transport protocol encapsulates everything inside of a
CDATA segment. To be honest, I'm RELYING on the way etherx encapsulates the
data to handle NON Jabber traffic..
> b) transport and router
> general thought (as well as what I've seen in the documentation) is we'll
> have a reliable (TCP) connection between the transport and router. We
> assume this! This is only available on a TCP/IP network, which by the
> of Jabber we cannot have network-level assumptions of this sort. New forms
> of intra-level communication will appear. Example: direct router access as
> seen in the new direct jabbertransport access and direct etherx access via
> IPC/shared memory.
Ok, confusal here. I *THINK* I grasp what your saying here, but technically
speaking, there is no reason why there HAS to be a persistent connection
between the router and the transport. Who ever said that? Granted, THERE HAS
TO BE A CONNECTION LONG ENOUGH to transfer the data, and we cannot 'split' it,
but it does nOT have to be persistant. Shared memory I'm not getting. Shared
memory doesn't work anything like a socket connection. Please, explain more
regarding what you mean?
> c) router and router
> We've also made the assumption communications between routers will be
> only. The XML streams recommended implementation has given direct support
> for this. A router on a unreliable network would be forced to understand
> parse) the contents of a "properly" implemented Jabbertransport. As it is
> also stated in the plans for our routing system, in general, we cannot have
(*BANG*) That was my remaining brain cell exploding. No one has stepped
forward and implemented any other protocols beside's TCP/IP. There is NO
REASON why someone could not add that capability. I bet technically it
wouldn't be all that hard to rig in something like IPX.. (Ok, I'm gonna say
it, but EEEEEWWWWWWWw!!!!)
> Rather than force network requirements upon our communications layers, we
> should reduce the needs of our REFERENCE transport and router. XML
> streaming, as an example, should have recommendations for short/burst
> connections and streams. In that, jabbertransport would need to communicate
> with etherx in much shorter (hopefully, a single message per connection)
Again, there is nothing saying that the transport needs to stay connected.
Etherx should be able to spool messages when the transport is not connected,
not a problem. Actually, one of the reasons when we where looking at the route
tag that I mentioned archived, simply becouse this is what etherx would do when
it can't send the message, and basically spools it offline to ensure the
> <silver lining>
> There is hope though! I can see an improved T&R (JabberBox) protocol which
> allows for route-checking, and more importantly a way of querying the MTS
> (maximum transmission size) and whether a connection is "reliable." This,
> unfortunately, would only be on a transport-to-transport basis. However,
> remember we want all the processing in the transports and not the routers
> (or clients to a level).
> </silver lining>
Yes, we want the processing of the XML messages within the transports, but
I'd suppose that we could setup the XML streams to allow fragmented XML
streams, allowing The streams to be split up.. (Oh dear god, what do we do
with the routing data when it goes two different ways..). Heck, we could send
the XML streams as larger sized UDP packets.. That's as unreliable as you can
> I can imagine posts of "well, then we can the unreliable systems be FORCED
> to code a reliable protocol underneath Jabber." However, I, as a developer,
> would not appreciate network transport requirements to come bundled into
> this new "universal" communications system. It might even give me reason to
> move to a project which didn't require even MORE coding on my part.
This is all at the stream layer, IMHO. The Jabber protocol that most people
have been using/looking at is a TCP/IP based protocol, no questions asked.
That's what Jabbertransport is currently IS. I would like to see, for the
reasons you stated, that etherx itself support fragmentation, etc of messages,
and perhaps even tag the streams with 'Packet ID's'. This can all be done with
what we have now. I don;t think we've been veering AWAY from a non TCP/IP
oriented situation, I just don;t think we've headed twards it either.
To that point, I'd also like to say we've been gearing it twards person to
person IM. This fits in your example, as when I want to send/recieve SMS
messages via cellphone/pager. The data transfered may not be someone saying
'Hello, how was your day..' type of messages.. It could easily be something
like log file entries, public key transfers, etc.. etc..
Now, that's not to say we've geared AWAY from this, we just haven't focused
> We want to take over the world, let's give the world a reason to take us
> with open arms.
Good way to put it. I get what your trying to say, I just perhaps don't
agree with the idea that we're straying away from anything BUT TCP/IP..
<< Wanted: One decent sig >>
<< Preferably litle used >>
<< and stored in garage. ?>>
More information about the JDev