Why is it that when someone is behind a firewall, I can send them a file, but they can't send me a file? (I am behind a router but I am the DMZ host, so everything passes directly to me, it is as though I'm not even behind a router, so don't tell me that the router is the problem, and yes, I do have my mIRC configured to use my real ip, not my LAN ip)

It shows that the person and I can connect to each other since I can send them the file, but why can't they send me a file? Couldn't it just initiate the connection in the same way it would if I were to be attempting to send the file, then go ahead and transfer from the other person's end to my machine?

And, correct me if I'm wrong, but, shouldn't it be the other way around as well? Why is it that I can send to someone who is behind a firewall, but they can't send to me? That seems very backwards to me.. :\

Umm, this is the feature suggestion forum, not the bug report forum/help forum. Also, why is it necessary that you post 4-5 different posts one right after the other, you know, you could combine them. In any case, I'm behind a firewall on a LAN and DCC works perfectly for me, so it means you're doing something wrong, not mIRC.

Another suggestion: Simplistic direct connect alongside the more complex way of connecting using the "socks" commands.

It'd work similarly to a DCC connection, except there'd be no window to view the text, a port could be set to connect on, it listens on a certain port or ports and there could be modifiers set to do things on connect, failed connect, and disconnect.

example set of all parts of this:
Here 0.0.0.0 corresponds with the true ip of the computer, so that it binds to that ip (instead of the computer's LAN ip, if it has one). 1.1.1.1 corresponds to the ip of the computer the script is connecting or connected to.

The command after the modifier gets set off when the connection fails (-f), connects (-c), or disconnects (-d).

example of a script created with this:



get the drift? It'd be something very easy to script, not complex at all (unlike the gaggle of 'socks' commands *shudders*).

Now, I know I'm going to get the reply "just use the socks commands..", so I'll say this now: I'm suggesting this as an addition for people who don't want to bother with the socks commands, and don't want to use DCC connections for their script (as that gets messy. It's very ugly and the port that it connects on can't be set specifically).

You obviously didn't get what I was saying.. It's not a bug, it's the way mIRC DCC connects. My suggestion is to make it try to connect "both ways" (whichever ways those ways are), because one of the ways connects, the other doesn't. If It tried connecting both ways, then it is logically safe to assume that It would always connect, at which point it could then start the transfer.

It's the way the network works dude, it's not a bug in mIRC.. A lot of people connect to mIRC while at work, and most of those people are behind a firewall and they cannot forward the information coming in on the DCC ports to their machine. The connection can be initiated, however, it just has to work in reverse to connect. Get what I'm sayin?

So you're asking mIRC to rewrite a standard? That would then mean that mIRC would not be able to DCC with any non-mIRC clients.

codemastr: type /help DCC Socks5 Protocol
you'll notice that when mirc using socks5 protocol
it use mIRC's, modified, DCC handshake protocol
so why not just use direct connection but mark as "behind firewall", just let client connect the other which not behind firewall
a script already done it, u many seach for it
it would be nice it mIRC internal support this mark as an option
because scirpting dcc is a CPU eater

and remote bind on socks5 should be also supported for DCC

As the others are rambeling about the other stuff I take this one
-----

DCC might seem backwards... but it's logic...

If UserA wants to send something to UserB, he/she then types the /dcc send UserB FILENAME command.

This in turns starts to listen to a random port (you can specify the range of this) ... and sends a CTCP to UserB, the CTCP goes through the IRC server just like normal messages/notice ..

The CTCP looks something like this:
dcc send 40.72_win9x.exe 3654426342 4944 12528219

The first set of numbers being the IP (in long/sort format, don't really know which if which ... check $longup)
The second set of numbers is the port
The Third set of numbers is the filesize in byte

UserB (the one that gets the file from UserA) now has a choice to either connect to the IP PORT and begin saving the file ... or dismiss the whole thing

---


-----

aarrgghh: I like your diagram. Would you mind also drawing one up that explains Resume and Pasv Sends?

Thanks

Finally, someone who is actually trying to be helpful, not arguementative..

codemastr:

Ok, first off, it'd be pretty easy to make this way of DCC connecting backwards compatible for compatibility with other IRC clients..

Secondy, don't roughly 63% of all users on IRC use mIRC?

Thirdly, how hard would this really be to impliment anyways? I don't see why it'd be very hard at all, but the benefits would be great.

A suggestion to you: You really shouldn't be so cynical.. Jeez man, chill?