[jdev] Multiple/parallel file transfers

[Justin Karneges]

On Friday 25 March 2005 07:27 pm, Anthony Ortiz wrote:
> I saw the fast-mode article last month while researching how to
> implement the bytestream file xfer and I thought it was interesting to
> look into at a later time. Since you've reminded me, I have a
> question... given the following :
>
>   <iq from="bob" to="alice" type="set" id="s2">
>     <query xmlns="http://jabber.org/protocol/bytestreams" sid="mySID">
>       <streamhost jid="bob" host="private.bob" port="8000"/>
>       <streamhost jid="bob" host="public.bob" port="8000"/>
>     </query>
>   </iq>
>
>   <iq from="alice" to="bob" type="result" id="s2">
>     <query xmlns="http://jabber.org/protocol/bytestreams">
>       <streamhost-used jid="bob"/>
>     </query>
>   </iq>
>
> How do you specify which streamhost was accepted in the reply?? All I
> can see is that the streamhost with jid "bob" was accepted, but that
> could have been private.bob or public.bob.

Does it matter?  Bob owns both of those interfaces.  In the event that Alice 
can reach both private.bob and public.bob, Bob should only accept one 
incoming connection.  Then the answer to your question is obvious.

> You do mention something 
> about the initiator throwing out an extra <CR> (extra??? so there were
> previous ones???) into the socket stream... does this mean that the
> target is to expect a carriage return from the initiator in the
> streamhost of choice?

There is only one CR.  And yes, the target should be expecting a CR.

The logic basically goes like this:

 1) if the initiator successfully reaches one of the target's streamhosts via 
SOCKS, then the initiator returns iq-result and a CR over that stream.  Both 
sides then know which TCP channel to use.

 2) if the target successfully reaches one of the initiator's streamhosts via 
SOCKS5, then the target returns iq-result and waits for a CR on either this 
stream or any other stream that the initiator might still be forming.

-Justin