DoS processing from untrusted sockets (and other threads)

Question

This advice confused me. It looks like the -buffering line makes the input buffer infinitely large when I thought that line buffering only affects the output flushing? Can't I use -buffersize 5000 with the -buffering line to protect me from people sending long lines? If I can, what good is chan pending ? To find out when a buffer is full without a line break in it?

Or are there two different buffers? The one that only reads data to save time, and the one that has commands like gets and read uses?

EDIT: Or is the problem only when using gets because it does not return partial strings? Does gets stream into infinite large buffer mode, because otherwise, if the buffer is filled without line breaks, it will never be able to return it? Is this the "line buffer mode" TIP talks about?

Answer 1

Firstly, the -buffersize option is for output, not input. I have never needed to install it in the last few years; Tcl buffer management is pretty good.

Secondly, the -buffering option -buffering also for output.

Thirdly, you are vulnerable if someone sends you a very long string, if you use blocking channels. You simply do not have the opportunity to do anything else but wait for the end of the line (or the end of the file).

But in non-blocking mode, everything is more subtle. You get a readable fileevent for the channel (not related to files, but you can better check their size, and this is usually not a problem anyway) and run gets $theChannel line , which returns a - 1. (If 0 or more, you have there is a full line.)

So what does -1 mean? Well, that means either the line is incomplete, or you have it until the end of the stream. You can distinguish between cases with fblocked / chan blocked (or eof to detect the opposite case), and you will find that there is no row yet. Now what? Check how much data is buffered using chan pending input ; if there is a stupid amount (where "stupid" is being rebuilt), then it's time to abandon the channel, since the other side is not beautiful (i.e. just close it).

I have not yet seen the real use for chan pending output , which would not be more pleasant with writable file files, but this is usually not a big problem: just using fcopy / chan copy to generate data from large sources in a (slow) output channel works fine without inflating buffers.