This is a must have!
IMHO dccserver is the worst idea ever. Active sends would be better by *HUGE* amounts.
I see passive down there. That's not even the right feature.
And yes, it's active sends. Dcc is already a passive send mode. Misconfigured NAT's can get Gets all the time, but can't send Sends. This is because the dcc protocol is passive.
If you're waiting on two sends from two different people. Who send on different ports. You're screwed. You can't open a dccserver on port 59 and 433 at the same time. You are forced to lose one. (you could set up a kludge if your nat has external to internal port routing)
Dccserver has an error which makes the name `Tat into the name _Tat when they exchange the nicks.
It's possible to redirect sends with DCC, yet, not with DCCServer.
Dccserver will take your word for whatever you say your nick is.
Dccserver is server independant, so it's not actually sure which server the person it is sending is on. So it mislables the sends and gets from time to time.
Dccserver can't be used on servers which protect hostmask (usermode +x), because the dns will always fail.
Dccserver is an always open port.
Dccserver (as far as I can tell) doesn't allow a person to run the built in fserve through it.
Dccserver has to be turned on, with a lot of complex garble that you can't get the average idiot to type. (it comes up).
Dccserver needs to be manually changed for each and every server with a slightly different setup. Dcc just has a bunch of ports it can get with.
DaveC mentioned that if the other computer doesn't have their nat setup right it's moot anyway... well the same is true for Dccserver. It needs the port opened on itside. And the user who opens the port on the NAT doesn't pick what one it is. It's picked by the server. So you need to reconfigure your NAT each time a server has a port you don't yet have open.
Dccserver sucks.
Active sends would work the exact same as passive sends. Once the connection is open, the connection is open. The code for the rest of the way is the same.
User1: DCC SEND <file> <longip> <port> <size>
User2: DCC RESUME <file> <port>
User1: DCC ACCEPT <file> <port>
User2: DCC ACTIVE <file> <port> <activeip> <activeport>
User1 connects to User2 at <activeip> on <activeport>
It's one extra line. (Although, implementing Rsend and Recv would probably be better than my example extension.) In fact if one user is trying to chat another user. And that user dcc chats the first user. mIRC will actually make the trying to connect dcc chat, into the accepted the dcc chat window. If somebody tries to fserve you and is failing, you can dcc chat them while their window is open and it will connect.
Or at least.. Add in a way to turn off the ack packets in dcc sends from the recieving client. It would allow for DCC sends uploading to FTP servers, and downloads from FTP servers via DCC sends with very well setup scripts. Those return packets are worthless anyhow, acks are built into tcp/ip stack. They are just worthless overhead. Being able to turn them off would be great. Pdcc is on quite often anyway. Usually making them completely moot.
