[JDEV] Re: OOB filetransfer negotiation

[Mathew Johnston]

I agree totally, there must be a way to set active vs passive on normal
P2P connections. I was just comming up with a solution that could get
around firewalls as long as they could get to port 80 :)

Mat.

On 16 Aug 2001 15:36:44 -0400, Simon Guindon wrote:
> I believe any connection like this, be it voice chat, webcam, white board,
> file transfers, all should be P2P if possible.  This should be made possible
> by some sort of negotiation process and if its found that both machines are
> behind a firewall thats not accessible then do the proxy method whichever
> way that is done.
> 
> Atleast this makes for possible faster interaction and takes load off the
> server thats doing the proxy stuff rather than everyone defaulting.
> 
> Don't forget, senders don't HAVE to be acting as the listening connection,
> if the sender is behind a firewall and the reciever isn't, then when they
> accept the file they can tell the sender "its ok I'm not behind a firewall
> you connect to me".
> 
> Those are my thoughts.
> 
> Simon
> 
> -----Original Message-----
> From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org]On Behalf Of
> johnston at megaepic.com
> Sent: Thursday, August 16, 2001 3:15 PM
> To: jdev at jabber.org
> Subject: Re: [JDEV] Re: OOB filetransfer negotiation
> 
> 
> A concept...
> 
> o On Server there is a CGI program
> o ClientA wants to send a file to ClientB
> o ClientA sends message to ClientB that says 'I wana
>   send a file, fileX, connect here to Server's IP,
>   TCP port 80'
> o ClientB goes and does it
> o Server returns in the http header OOB-Port: portX
>   where portX is some string
> o Server does not finish sending headers - it just pauses
> o Server and clientB stay connected
> o ClientB sends ClientA a message and says, 'server says
>   port is portX'
> o ClientA posts to Server with a variable port = portX
>   mime = mime/type and stream = base64 encoded file.
> o Server finishes the http header to clientB giving the
>   mime type, and then feeds clientB the stream from clientA
> 
> I know it's kinda silly, but it'd work and it would allow the web server to
> not temporarily store the data that's being sent like you need to do with
> the upload and reference method.
> 
> Mat.
> 
> On Thu, Aug 16, 2001 at 01:20:27PM -0500, temas wrote:
> > Sebastiaan 'CBAS' Deckers wrote:
> >
> > >>There are two workarounds that I know of to the firewall problem:
> > >>(1) Sender uploads the file to a public server someplace, i.e. your
> > >>storage area on your ISP account. Works best with FTP or WebDAV access.
> > >>Then you send the receiver a URL to where the file got uploaded. I hear
> > >>that some Jabber clients already support this.
> > >>(2) Someone runs a public "relay server" that accepts connections from
> > >>two machines that want to communicate, then relays socket traffic in
> > >>both directions from one to the other. There is a prototype protocol and
> > >>implementation at jabber.org (but I've lost the email that announced
> it.)
> > >>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev