[jdev] Re: bytestreams and Psi

[Mats Bengtsson]

Thank you all for the answers.

If I focus on the situation where no proxies are available (most common)
and only one of the initiator/target is behind a NAT, there is no reason
why it should work only one way (when target behind NAT).
Instead of the target is acting like a client and the initiator as a server,
they may very well switch there roles, and the target acting as a server while
the initiator as a client, but with the difference that the client is PUTting
the data instead of GETting it. 

Right now I cannot judge if the 'fast' extension is the smartest one.
The negotiation to avoid race conditions by sending an 
additional [CR] character across the bytestream to indicate its selection 
seems crude. My first impression tells me that host negotiation shall take
place in the xml stream, but I might be missing something important here.

/Mats

> Mats Bengtsson wrote:
> > One of my Coccinella users are using Psi behind a NAT while his friend is not
> > behind a NAT and when doing filtransfers when the initiator is behind the NAT
> > have observed two peculiar things:
> > 
> > Are they having there own proxy host? Or what does the <fast/> element mean?
> > 
> > The target is offering a streamhost ???
> > 
> > Any ideas?   
> 
> 
> These are File Transfer extensions proposed by Justin which didn't make
> it into the JEP.
> 
> Read here: http://delta.affinix.com/specs/stream.html
>