mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
I'm still encountering conflicting information about the differences between these commands even after searching this forum's archives.

Maybe someone who's compared them at the packet sniffage level (or Khaled, who knows his own source code) can answer this definitively once and for all.

What are the absolute technical differences between "/pdcc on" and "/fsend on"?

I know this much: that the DCC protocol uses a primative ACK system wherein the sender's next packet isn't sent until the recipient's ACK for the sender's most recently sent packet has been received by said sender. The obvious result being pauses in what would otherwise be uninterrupted throughput -- and noticably too, because those pauses happen after every packet and are each equal in duration to the full round-trip ping time between sender/recipient.

Pfew. That said, the TCP protocol incorporates a similar ACK system, but eliminates the aforementioned pauses by allowing a certain number of packets to be sent ahead of recipient ACKs. As long as the recipient doesn't fall too far behind in generating ACKs, the equivalent of uninterrupted throughput is achieved.

So ... depending on what I read, some people suggest that "/pdcc on" causes mIRC to do the same thing - to send packets ahead of ACKs to eliminate those pauses.

But others say "/fsend on" does that.

I doubt there are two commands that do exactly the same thing. smile

So, which command causes packets to be sent ahead of ACKS; and, then, what does the other command do, technically?

Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031

Originally Posted By: pishposh

So, which command causes packets to be sent ahead of ACKS...


I'm not sure what pdcc does, but fsend does exactly that, but it will still wait for all the acks before the send is complete/successful. I see it happen from time to time that I'll complete sending all packets to someone before receiving their first ack, and then when the acks eventually catch up the send is complete.

~ Edit ~
According to this DCC tutorial on mirc.net, pdcc does the same as fsend without disabling error checking.


Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
Thanks. Yeah, I found that DCC tutorial at mirc.net while researching this. However, its meaning was less than clear. The author appeared to be describing both commands as having the same effect (with the exception of "/fsend on" also eliminating error correction). But he also seemed to be recommending that /fsend and /pdcc both be on. And that made no sense to me, as according to his own descriptions of the commands, turning on /pdcc would cause no additional effect if /fsend were already on.

So I assumed there must have been yet another difference between /fsend and /pdcc that he wasn't aware of.

On another forum, I found this: "Emperical testing with a newer version of mIRC shows that fsend, which is on by default, causes mIRC to send 10 +/-1 speculative packets. pdcc (not on by default) bursts the entire file at once."

But there too, I assumed the author must've been wrong, because "bursting the entire file at once" = the equivalent of TSEND (i.e. no ACKS ever!), a feature mIRC doesn't support to my knowledge.

Heh. This is why I'm fairly confused. So much conflicting info.

If Khaled sees this, I'd love his insight.

Last edited by pishposh; 13/06/08 06:14 PM.
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031

Both on doesn't make much sense to me either if the only difference is error checking. I would think that if this were the case, enabling one would disable the other. I agree that an explanation from Khaled would be nice.

Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
I guess the details are top secret.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
It may be of interest to note that in the last year (at least), Khaled has made 0 posts in the Support forums-- he leaves this section for the community to field questions, so this isn't exactly the best place to hold a conversation with him directly. He's not ignoring you.. he just probably doesn't look here.

On a sidenote, you can easily verify mirc's behaviour by inspecting the network traffic going in and out of your machine during a DCC transfer. Try Wireshark (formerly Ethereal) packet sniffer with /fsend on and then /pdcc on. One of them will hide acks.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
These commands were added very early on in mIRC's development and were experimental at the time. They perform the same function but in slightly different ways. If /fsend is on, up to ten packets are sent ahead of acks, and if /pdcc is on, unlimited packets are sent ahead of acks - in some situations.

The /fsend option is more reliable - that's why it's on by default in new installs. I could remove it as an option and make it permanently on, and take out the /pdcc option completely, however they've been there for a long time and there's no real harm in leaving them as they are.

Joined: Aug 2006
Posts: 167
P
Vogon poet
OP Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
Thanks, Khaled. I appreciate you offering details - especially knowing now that you're no longer a regular. (Which makes me feel horribly guilty asking as a follow-up what 'some situations' are re: PDCC. wink )

Anyway, I agree with leaving /pdcc and /fsend intact. It's nice having that configurability handy. "/fsend off" gives the possibility of perfect DCC RFC compliance, and "/pdcc on" surely gives someone, somewhere a little extra throughput.

With broadband speed lust being the norm now, I've been wondering to myself lately if there's any way left of optimizing average DCC speeds without violating the DCC "RFC". Two things have occurred to me: larger packet sizes, and basing packet sizes on multiples of the sender's MSS (rather than on multiples of 512 as now). So if my client detected that my current MSS was 1460, then it would give me packet size choices of, say, 730 (1/2 MSS), 1460, 2920, 5840, 11680, 23360, 46720, and 93440.

If you think there's any logic to this, toy with it some time and see what happens. Else, disregard. smile

@Argv0 - In fact, my last visit to this forum was 11 months ago. Khaled was active then (he responded to some of my posts), and I didn't know anything had changed. So if my "top secret" remark seemed arrogant, it wasn't meant to be. I thought he was still as active as ever. smile

BTW, I thought about using a packet sniffer too, but realized I'd never truly get to the bottom of the mystery because I'd also have to rig the recipient to somehow stop sending ACKs at some point in order to observe the sender's behavior in response.

Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031

Originally Posted By: pishposh

I thought he was still as active as ever. smile



He's not really less active, he's just most active in the bug reports forum and possibly skips the other forums altogether most of the time. Only he could say for sure why.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I was going by the "View Posts" link when you click on Khaled's username, which shows all of his posts in the last year in the Bug Reports / Feature Suggestions forums exclusively. I never meant to imply he's not active, less regular, or anything of the sort. I was merely pointing out that this is the last place you would find him.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard