Set LINELEN to 8k for clients that support long messages #65
Conversation
|
You can reuse the
this sounds like a different bug that would also be triggered if clients sent a single command split into two packets (eg. because it sent previous commands in the same packet) |
This matches the value already negotiated for cap multiline. I think we could go up to 16k without difficulty, but 8k is probably sufficient. This also tells gen_tcp to use a 16k buffer; with the default settings, long commands sometimes get split across multiple reads, with unfortunate results.
Done, thanks for the pointer.
It's not a packet-splitting issue, I was just speculating as to why that's the default buffer size, since it's suspiciously close to the ethernet MTU of 1500. It looks like erlang IP networking sets the default as 1460b, and will not expand it automatically. Thus, if you ask for line-buffered mode without specifying a bufsize, and get a longer line than that, you will get 1460-byte line fragments followed by whatever's at the tail of the line. Which explains the behaviour I was seeing -- with just the change to LINELEN, weechat would cheerfully send long commands and they'd show up in the IRC protocol handler as multiple lines of ≤ 1.5k each. In the commit as revised I set this to twice the LINELEN, just in case of misbehaving clients that (say) forget to take into account the command overhead when measuring out long commands, and base it too on |
|
Ah right, that makes sense |
|
Sorry, I messed up -- there's a line missing from handler.ex. Fix is here. Perplexingly, even without that line |
This matches the value already negotiated for cap multiline. I think we could go up to 16k without difficulty, but 8k is probably sufficient.
This also tells gen_tcp to use an 8k buffer; the default buffer size is about 1.5k (one TCP packet, maybe?) and cuts off longer commands, with tragic results.