You only said that it was unwieldy, not that you wanted to avoid it, until now

Basically you need a rendezvous service , I guess. NetMeeting might be it.

I've never used it.

Can one send/receive files with NetMeeting?

yes, file transfer is built in

Wonder if it'll work better than the file transfer in all the IM packages I've used. I'll give it a shot.

I'd tend to do this in Unix, but I believe that PuTTY can handle SSH tunnels. You can download it from http://www.chiark.greenend.org.uk/~sgtatham/putty/docs.html
Look for tunnels in the docs.

Putty is an SSH implementation, from what I gather. How can SSH help me connect directly to another user when we're both behind firewalls? Don't we need an SSH server for that sort of thing?

Ah, good point. I forgot that PuTTY is just a client and one of you would need to be a server.

Could you run a web or FTP server on a high port that isn't firewalled (assuming the FW isn't stateful?)

Are you both behind firewalls that are uncontrollable? Or saying, at least, that we should assume that?

Tony,

I have about 110 gig free (RAID 5 with nightly backups) on a T1. Unlimited transfer unless it gets abused. PM me for an account.

Are you both behind firewalls that are uncontrollable? Or saying, at least, that we should assume that?

Ideally, I'm looking for a long-term solution that will work no matter who I'm communicating with. At the moment, I'm behind a firewall that I can control, but I can't always assume it'll be that way. The person at the other end of the line may often be behind a firewall they can't control. So yeah, for the purposes of this exercise, let's assume that one or both of the parties is behind an uncontrollable firewall.

Thanks for the offer of server space. I've also had offers in private messages. I will keep these offers in mind. Ideally, though, I'd like to find something that didn't depend on someone else offering server storage space.

Thinking about it (which hurts too much this close to new year ) I think this is actually the opposite of the USB scenario, you have two devices that are both able to connect to other things (websites) but cannot be connected to, this makes them the same as a USB host, so all you need to fix the problem is a USB LinQ

But seriously there should be a pretty easy fix that should be small enough for you to host almost anywhere, assuming:
- The upload mechanism the same as the one used here for attachments works OK for both of you
- The download mechanism that most places use where you click a link, it displays a page showing that a download should automatically start, then the download starts works for both of you.

What then happens is the file 'receiver' goes to the a webpage, and a download is triggered 'automatically' at the same time (well give or take whatever the download timeout in the browsers are, I am guessing you may have a couple of minutes) the 'sender' chooses the file and uploads it from another webpage, each uploaded chunk of data gets immediatley sent to the person dowloading so there is no data actually stored on the server. Actually that does sound a lot like the USB solution, something dumb in the middle just forwarding data.

I guess it should be a fairly simple task for someone who knows that sort of stuff, or has acess to the upload and download examples I gave, I may be interested but I am hacking USB at the moment

To be generic, if that's the case, then you can only be assured (and even then, not really) that each of you can make outgoing TCP connections. There's no way to match those two outgoing connections together without external help. And since you don't want to rely on the kindness of strangers, your only choice is to rely on the kindness of some corporation that provides such a service.

Right now, you're trying to do that with IM services, but the file transfer stuff they use happens not to work with your firewalls. Ideally, they'd just multiplex the messaging and file transfer on the same stream, but it doesn't appear that any current IM service does that, not even Jabber. Any other facility out there is likely to charge for it.

You could probably figure out a way to actually get two outgoing TCP connections to join up with some deep magic, but I imagine that's outside the scope of your request, and even then might fail depending on how your firewall rewrites ports.

So, for right now, I think you simply can't do it.

Funk TCP/IP. Can anyone say Xmodem?

Almost everyone has a phone line and modem collecting dust.

There's no way to match those two outgoing connections together without external help.

Good point. That does seem to be the crux of the dilemna.

Ideally, they'd just multiplex the messaging and file transfer on the same stream, but it doesn't appear that any current IM service does that, not even Jabber.

Yup. That seems to be the crux of the problem with the IM services.

You could probably figure out a way to actually get two outgoing TCP connections to join up with some deep magic, but I imagine that's outside the scope of your request, and even then might fail depending on how your firewall rewrites ports.

Ah, but if it could be figured out, and one could write such a utility, I think one would have a very popular little applet to sell. Hm. Wonder what that magic would be? Perhaps something that piggybacked on an existing IM service's connection.

Fair enough. But transferring a file that's too big for many email servers over long distance at something less than 56K could be quite expensive. It also requires a significant amount of effort, which was one of the prohibited things in the original RFP.

How about writing a pair of perl (or python, since Tony's already got that installed) scripts to chop up the file and send it via email and then reassemble on the other side? Still too much effort?

File chopping works, and I don't need Perl or Python to do that (just a zip program). It's just a pain with the multiple email messages.

This is probably the best solution, as there isn't any way with two NATed connections to get them to talk to each other. (Bug or Feature? You decide) The problem of course with using a server in the middle is that the file has to be transfered entirely to and from the server.

The problem stems from how NATed connections work. If you're behind a NAT proxy, paths to your computer only become opened up when you send a packet out, or when you set a port-forwarding rule(which is eliminated by Tony's no-firewall-conrtoll mandate).

Does anyone know if/how a P2P client gets around this? I know kazaa works for me behind a NATed connection, but I'm not sure if transfers between two NATed connections work out or just fail.

What I was thinking of was figuring out how to make the incoming and outgoing ports match on both sides beforethey were actually sent. It's likely that that would be in violation of the DMCA, though, and therefore probably unsalable. It would also depend on knowing how the firewall rewrote those packets. Since they often rewrite port numbers in addition to IP addresses, you'd still have to have someone on the outside looking to see what those new port numbers were in order to generate them properly on the other side, and if both firewalls did that, which isn't unlikely, then you'd be totally screwed.

However, you could figure out a way to write a custom IM app that was specifically built to transfer files via the IM service itself, but most IM services have a jabber-killing feature whereby if a client talks too much, they get cut off, so you'd have to pipe it through slowly, which wouldn't be ideal, either.

Perhaps something that piggybacked on an existing IM service's connection.

Perhaps you could have something that could do the following:

a) packetize your existing file into nice chunks
b) ascii armour it
c) spit the chunks over the existing IM connection as ascii data
d) reassemble the chunks on the other side.

You know, the xmodem idea isn't that far fetched. The only difference is that instead of dumping the data block over the phone line, you would be dumping it over a text IM session, probably proxied via http...

Still, it sounds like reinventing the wheel. If only the IM clients actually worked for sending their data files across the existing sessions without trying to open a different port...

If Tony controls his firewall, he can run a webserver off his machine (as I do). I have a Win2k box that sits on my DSL line running Xitami. I run the server on port 81, so some anonymous h4X0r doesn't easily stumble upon my machine.

If he doesn't want to do that, maybe he can ask his ISP nicely to raise his quota. I had an agreement with my former ISP, CyburbanLINK, that I could upload a huge file to my webspace as long as it was taken off in a timely manner. Local ISPs are usually very nice.

I am actually behind a pretty tight firewall (even the IM clients don't like it) and the upload and download examples I gave still work for me, if they work for Tony then that would be where I would start looking.

It's likely that that would be in violation of the DMCA

Isn't *everything* in violation of the DMCA though? I took a dump yesterday that resembled the cover to The Rolling Stone's "Tattoo You" album and I got a letter in the mail today telling me I violated the DMCA.

It does sound like a good idea. Still requires a server to sit in the middle, but it's not as bad as asking for FTP space from someone.

Tony,

I think you are going to be stuck with someone in the middle however you do this, as neither end can be directly conected to. If you have the program/script/webpage yourself you can host it wherever you want rather than using some IM piggyback that dies when the decide to change their 'private' protocol.

If you have the program/script/webpage yourself you can host it wherever you want

But it requires write-able disk space somewhere, though. Still, I might be able to work that out with my ISP.

I got lost in this thread just after tony said large file

In my line of work we don't use large files anymore we use air powered grinders

ROFL

hi Tony,
If you want to go the file chopping and delivery via e-mail route...

There is a commercial product (for windows PCs only) called Mailrules developed here in New Zealand.

I've used the product and it works well.

One of the features it has is the ability to automatically zip up and send entire folders/directories (or just single files if desired).

It can automatically Triple-DES encrypt the outgoing files and will automatically chop up into smaller chunks large files and send multiple messages with automatic chunk reassembly and decryption at the recipient (any missign chunks are detected and re-requested), plus you (as sender) can get email confirmation back that the file(s) made it to the other end.

So you can get a end-to-end transparent file xfer using Email. This transfer can be "one demand" or scheduled. It can be used to do the equivlaent of auoitmating large ftp transfers just using email.

It will do sending and receiving and will poll selected folders for particular files, and when one is found, will then zip ip up and email it to the recipient using the rules you configured.

If you're interested, visit This Link for the details and a download of a 60 day trial version.

I must point out that I don't get any benefit from recommending this program - I only recommend it because its useful and sells well around the world.

But its only Windows for now.

If you do try it and like it, the guys are open to suggestions for improvements - just email them your suggestions - they may well incorporate them sooner than later.

I tried using NetMeeting recently, but I can't connect to their directory server.

The software is coded to use "http://directory.netmeeting.microsoft.com" as the directory server, but that site doesn't respond, even in a plain old web browser. Didn't respond last week, doesn't respond this week. It's almost as if it's been taken down completely. However I don't see information to that effect when I search the MS knowledge base on the topic.

Has Microsoft simply dropped support for the Netmeeing directory server?