Difference between /fsend and /pdcc? (Khaled?) - 13/06/08 04:26 PM
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.
So, which command causes packets to be sent ahead of ACKS; and, then, what does the other command do, technically?
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.
So, which command causes packets to be sent ahead of ACKS; and, then, what does the other command do, technically?