[standards-jig] JEP 0033, Packet Headers, Issues

Joe Hildebrand jhildebrand at jabber.com
Mon Jul 22 19:51:05 UTC 2002


Inline...

Ben Schumacher <ben at blahr.com> writes:

> On Fri, 19 Jul 2002, Adam Theo wrote:
>> First, I wonderif needing to expressly send the multi-address
>> packet to a "multicast component" is really necessary? If
>> there are more than one intended recipient (through to, cc, or
>> bcc fields), the packet must be addressed to a
>> "multicast.your.domain" component, which will handle the
>> forking of the message to all recipients. A question, then:
>> will this multicast server have to be expressly specified by
>> the sender, or can they address the packet to one of the "to"
>> fields and have their server catch it and fork it
>> automatically? Otherwise, this seems to add too much
>> complexity on the hands of the sender. Not even normal Jabber
>> users would know to do this, since it is not like email at
>> all. I think an alternative needs to be found, such as the
>> sender's server automatically checking for forking, instead of
>> a specific multicast component.

How does the client know if it has to send to multiple recipients
or not, then?  You have to be able to tell if the server is doing
the demux, or if the client is going to do it.

> The spec does allow for a server to have built in processing of
> multicast packets, it just doesn't explicitly state it. That
> being said, I'm not sure what the problem is. When you say
> "will this multicast server have to be expressly specified by
> the sender," I will assume you are using the term sender to
> reference the "end user." Is this assumption correct? If it is,
> then I think you should rethink the issue. A developer could
> easily make a client that does this process automatically,
> wouldn't this be more intunitive. For example, when I (as a
> user) am sending a message, and I'm trying to send to multiple
> recipients, my client (Exodus) could already know that a
> multicast component is available and address the packet
> accordingly. Wouldn't this seem to be a more intuitive design?
> And since Exodus already has support for "broadcast"
> (multi-recipient) messages by simply sending out multiple
> packets, it would make sense to add code to take advantage of
> this component and conserve bandwidth.

Agreed.  Also, take into account that a sender may not have a
user associated with it at all.  Imagine a JSM that knows about a
header processor.  It could do a much better job transmitting
presence tags (e.g.) between servers.

>> Next, why not have all <address>, <field>, and <resent>
>> elements as direct children of the <header> element. It's not
>> like the <addresses>, <info>, and <trace> elements that are
>> currently the direct children have any meta information of
>> their own, so why not simplify things and remove an entire
>> layer of nodes from the packets? No data would be lost since
>> none of the elements needs any type of specific ordering to
>> work. They could be easily "jumbled" together for the sake of
>> not creating another layer that has to be traveled down.
>
> I think Joe's intention here was to ease processing on the
> server (component) side. The multicast component can step down
> (use XPath) to quickly locate the targets of this multicast
> message. If they are all at the same level, then it requires
> that *all* header elements are parsed, which could be extremely
> expensive if there are a large number of <trace>, <field> and
> <resent> elements. In the original version of the JEP, this
> structure didn't exist, and it was revised for this reason
> (IIRC).

Yep.  That's exactly it.  We started thinking about the
implementation, and it seems a lot easier with the new structure.
I'm actually working on an implementation at the moment, and
expect to find a few more refinements as I do so.

> And Joe, if I'm off on any of this, please correct me, but I
> believe I have a pretty good understanding of your goals.

Apparently.  :)

-- 
Joe Hildebrand




More information about the Standards mailing list