Forums Feature Suggestions Active DCC Sends/Chat

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.

I dont actually remember saying that, but it was likely I mentioned that its easier if the 1 server has its nat/firewall/router/iis setup to recieve on set ports than expecting that the 100's+ of recievers have theres setup correctly.

Most nat/firewall/router/iis well have no worries with outbound (unless set to) so the reciever of the file doesnt even know hes starting the point to point coms.

The most annoying thing I well say about a NAT on the senders side is that it well change the port number your using for the file transfer, it intercepts the "DCC SEND filename ip port filesize" and adjusts the portnumber (lets say from 5000 to 21050), but most of them miss the incoming "DCC RESUME filename port position" and dont adjust the portnumber back (so you get 21050) and mirc just looks at it and goes, HUH? im not sending anything on that port stuff them.


On the client needing to reconfigure his NAT, i have never seen this, the reciever of the file doesnt need to open the same portnumber as the sender, he only need comunincate to that sender of the files port number, I know this is the case as I have had several downlaods going when all the senders are using port 5001, while my end is connecting on different port numbers, (i just did one to ensure this netstat > TCP DaveC04:4145 xxx.xxx.xxx.xxx.centurytel.net:5001)


I do however think having Active sends is a nice idea also, fservers could use a fall abck system, if the passive send doesnt work try a active one on the reciever, However 3 to 1 that that is going to trip some firewalls to detecting it as a penertration attempt and block the IP