lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Now you mention it, here's a related feature request
for the next LuaSocket. For line-by-line reading, allow
an additional numeric parameter for the max no of
bytes to read. Return at EOL or after max bytes,
whichever comes first. This avoids the need for yet
another (Lua) level of buffering whilst preventing
badly behaved line-based TCP clients (some Outlooks
spring to mind) which send more data than the RFC
allows, and possibly very much more. (Have seen
Outlook/Exchange msgs with 'lines' 2MB long or more.)

I have actually thought about implementing this one. I even
wrote partial support for it in the form of a "*<n>l" or
"*<n>a" patterns, where <n> gives the maximum size. The functions would
return "truncated" if the maximum size
was reached before the end of the pattern.

But then I noticed that any serious server would be doing
non-blocking I/O anyways (which already returns partial
results).  At this point, it becomes trivial to check the
size of the accumulated pattern within the reading loop, and
abort if needed.

Another featurette which could be considered as a
generic version of your patch is to have a single char to
specify the EOL char (you would just use a
zero byte). Reason for this is the occasions when
you want to know exactly what line of chars was sent
in a line-oriented protocol. The current definition of
a line is very convenient but does not allow exact
reconstruction of the input data (since CRs just before
LFs get silently eaten), so you can't, for example,
use line oriented LuaSocket reads to write a mail server
with  a 'strict EOL enforcement' -- lone LFs not
allowed -- option) and simply strip the CRs yourself.

I try to cover most of the use cases, but I am usually avoid
introducing to too much complexity into the library. I know,
each request seems simple, but once they pile up, things
become untreatable. Are there many protocols that behave
like this? Examples would be helpful.