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 >
