Ok, time to end this silly "buffer" thread:
1. any program buffers (that is your "char buf[1024];" type thing)
in proxies have 0 to do with buffer space problems - you usually have
many megabytes of virtual memory to make up proxy buffers with, never
to forget using files...;
2. TCP talks to itself, so that each end is aware of the buffer space
at the other end - it's called window size. Kernel TCP buffer space
is much more limited and must usually compete with other kernel
buffering.
The size of buffers on any intermeadiate nodes should not be a problem for
TCP applications, so long as the proxy can hold at least one entire "record"
if the protocol has such a concept. For FTP and HTTP, the end of a record,
and thus start of the next might be indicated by a linefeed, so the proxy
should be able to hold at least one entire "line" in whatever buffer it has.
How long a line may be is ually somewhere in the protocol spec. If that
size isn't specified and there is no way in the protocol to know, then you
might consider the protocol to be flawed.
Even then, this is only required if you intend on filtering on the contents
of those "records".
Cheers,
Darren
References:
|
|
