Register Log In

Forums Feature Suggestions DCC GET

Print Thread

DCC GET #125985 24/07/05 01:14 AM
Joined: Oct 2004 Posts: 24 D darkrift OP Ameglian cow
OP darkrift Ameglian cow D Joined: Oct 2004 Posts: 24	I think the DCC server should have another command in it ... DCC GET would work the same as DCC SEND but it would be the receiver that initiate the connection, that will send the file you have set for the nick initiating the DCC SEND that would fix a lot of firewall/router for some user what you think ? the way it's supposed to be ! UnderNet #scripting - #mircscripting

Re: DCC GET #125986 24/07/05 01:18 AM
Joined: Sep 2003 Posts: 4,230 D DaveC Hoopy frood
DaveC Hoopy frood D Joined: Sep 2003 Posts: 4,230	Quote: but it would be the receiver that initiate the connection It already is the reciever that starts the connection, thats why the sender must have a hole in the firewall.

Re: DCC GET #125987 24/07/05 01:36 AM
Joined: Oct 2004 Posts: 24 D darkrift OP Ameglian cow
OP darkrift Ameglian cow D Joined: Oct 2004 Posts: 24	I meant the receiver that wait for the connection, the sender connect to the receiver computer the way it's supposed to be ! UnderNet #scripting - #mircscripting

Re: DCC GET #125988 24/07/05 10:44 AM
Joined: Sep 2003 Posts: 4,230 D DaveC Hoopy frood
DaveC Hoopy frood D Joined: Sep 2003 Posts: 4,230	Quote: the sender connect to the receiver computer I see the obvious problem with this that the receivers firewall well then be incountered and so he well have to sort the problem out. In the real world its one sender and lots of receivers, this makes it much more logical that the one sender sort his firewall out than the multiple receivers. I assume your talking about a passive dcc, which can be already done in some ways as far as i know, but really how hard is it to sort a firewall/router out.

Re: DCC GET #125989 25/07/05 03:57 AM
Joined: Oct 2003 Posts: 3,918 Montreal, QC, Canada A argv0 Hoopy frood
argv0 Hoopy frood A Joined: Oct 2003 Posts: 3,918 Montreal, QC, Canada	quote from help file on dcc specs Quote: Notes: The Get protocol has been implemented in this way mainly because I'm assuming: 1) The client may not be able to open a socket to listen for and accept a connection (firewall etc.) 2) The DCC Server may only be able to listen for connections on port 59 (firewall etc.) 3) Since the client was able to connect to the DCC Server the first time, it should have no problem connecting to the same port again. Note that if you both have the DCC server running (and receiver opens port 59), then the receiver will be the one listening, as you wanted. - argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"

Link Copied to Clipboard