I think with a little effort, Khaled could add passive error detection for both the sender and the receiver, and even issue a /notice to the other party with what mIRC thinks has happened.
Here are some examples:
[*] Sender's is connecting from a local network, and the client didn't look up their internet IP address, so it sends 192.168.0.2 in the DCC Send/Chat request. The receiver's client should automatically detect that a reserved (invalid) IP address was sent, and /notice the requesting client this fact.
"Sender's client is misconfigured; does not know its own internet address. Try typing: /localinfo -u"
[*] Sender is connecting from a local network, and isn't forwarding their DCC ports correctly. The receiving client could /notify the sender that "Unable to get file from you at 123.123.123.123 port 4000; Connection Refused. Please open your ports!"
[*] Receiving client has filetype ignore enabled. It should notify the sender via /notice that "Sorry, I am not accepting files of this type. See: /help DCC Ignore"
These basic error responses can save Senders and Receivers a lot of trouble and debugging, and can be accomplished with existing DCC protocol. A 10 second flood prevention delay can be added, just like CTCP VERSION, so these /notice responses cannot be abused. mIRC can even display "Type: /HELP DCC Problems for assistance." locally, when a known error message is sent or received.
Put simply, DCC protocol does not need to be revamped... at least not for the sake of error detection and correction. (I'm pretty sure you agree on this point already; just for other readers.)
- Raccoon
