I'll once again (since a new version of mIRC has come out without this feature) propose a slight alteration of mIRCs DCC sending code to enabled more people to use DCC sends. An alteration that requires no changes external to the sending copy of mIRC, i.e. no changes to the DCC protocol (beyond the changes mIRC 5.4(1?) already made.
DCC sends have following negotiation sequence (give or take, I'm forgetting):
sender listens on port
sender -> reciever: DCC SEND filename ip port filesize
reciever TCP connects to port and the transfer starts
This reveals the problem: The sender needs to be able to accept incomming TCP connection by listening on a port, if he can't, because he is behind a firewall or he shares an IP with others (for example with a NAT), he can't DCC send.
Since mIRC 5.4(1?) there has been a different sequence supported by mIRC, passive DCC. It's specified to be used with firewalls but works in many other cases just as well (i.e. behind a NAT). The idea behind this is that the recievers listens and the sender connects, thus removing the problem altogether. This again from memory (the exact description is in mIRC's help):
sender -> reciever: DCC SEND filename ip 0 filesize
reciever listens on port
reciever -> sender: DCC SEND filename ip port filesize
sender TCP connects to port and the transfer starts
This is very much like how FTP solves the same problem (passive FTP) and this solutions works great, except for one tiny smudge. This protocol was intended for sending behind a SOCKS firewall and thus tied mIRCs implementation to this fact by disallowing passive DCC to be used if no firewall is configured. The ip sent by the sender is intended to be the firewall ip but for the reciever it makes no difference if this is the senders ip (or any arbitary number actually) instead. This limitation in mIRC implementation is not a flaw in the protocol or it's usefulness but rather a design decision. I keep trying to get this arbitary limitation lifted in future mIRC's, it takes (concievably) next to no implementation effort and would enhance the utility for some users. As a proof-of-concept that this setup works anyone with send problems should download an try:http://www.guldheden.com/~sandin/files/pasvdcc.mrc
It allows DCC sends using this protocol by adding it's own DCC send code. Liberate passive DCC in mIRC, make my addon redundant.
Please. I don't want or mean to repeat myself, but this is such a no-brainer and I've still not heard a single counter-argument.