> Well, doesn't that mean the limit is 510 characters including the command?
No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send:
PRIVMSG #channel :some long message
the server will proceed to send everyone else in that channel something along the lines of:
:your@hostmask PRIVMSG #channel :some long message
which will be limited to 510 characters (512 minus CRLF). Unless you're perfectly aware of how the server will render your hostmask, there's no way to know where the limit will end up.
(I incorrectly said earlier that the prefix is based on the server -- it's actually your client hostmask.)
> HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)
Re: message length, this does still sound like a limit on the implementation, and you could easily make IRC servers that have either longer messages (ircv3 has 1024) or no limit at all (although perhaps that's not a great idea)
> DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)
You're right, I was not aware of the acknowledgments. But this in previous response I said that a lot of issues could be fixed on a client side. DCC is also completely implemented with clients and similarly can be fixed this way. There apparently is already DCC XMIT standard which fixes latency caused by the ACKs (assuming our client wouldn't do same thing as Slack does which is upload files to S3 and share the URL)
> Well, doesn't that mean the limit is 510 characters including the command?
No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send:
the server will proceed to send everyone else in that channel something along the lines of: which will be limited to 510 characters (512 minus CRLF). Unless you're perfectly aware of how the server will render your hostmask, there's no way to know where the limit will end up.(I incorrectly said earlier that the prefix is based on the server -- it's actually your client hostmask.)
> HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)