[standards-jig] IBB: Making it all "go"
richard at dobson-i.net
Wed Apr 9 09:55:40 UTC 2003
> > 4.) Clarify the error states in the JEP, so that the behavior of the
> > stream in error conditions is well specified. In my mind, this is the
> > only outstanding point of discussion. The clarification should detail
> > what happens specifically when:
> > 4a.) The target goes offline (for any reason)
> What should we do about message packets that wind up going to the next
> available resource? As DW noted, this could be a low-bandwidth resource
> does not want to be bombarded.
> I hate to wreck the party, but as much as I like these latest ideas, I
> we may want to go back to just plain <iq> with wait-for-result. Sure,
> has the downside of extra turn-around time per packet, but at least it is
> issue-free (no counters, no delivery problems).
I think this is perfectly valid and it should not really be the servers
responsibility to protect the low bandwidth client or other clients from
file transfer packets that get directed to them (that were not really
intended for them since another resource went offline), IMO the file
transfer packets should never be able to goto another resource and also
should not get stored offline which really means they should be using iq
instead of message, also if iq is used there isnt really a need for the seq
stuff, since only one packet will be being sent at once, the only problem is
this may slow the transfer down waiting for the responses before sending the
next, but since this is only designed to be used as a fall back and for tiny
files I dont see this as a real problem, IMO iq is definatelly the way to go
as message presents a lot more potensial problems in the long run IMO. Also
using iq means it is not unnecessarily dependent on other protocols such as
x:event and x:expire just to fix the problems with using message as the data
transport which IMO are not a problem with iq.
More information about the Standards