Re: [Exim] [RFC] a general iplookup

Sheldon Hearn wrote:

>>this could be done with an simple protocol like this
>>(>> indicates outgoing and << incoming)
>>
>>---exim opens socket
>>
>>>>user@???
>>>
>><<forward@???
>><<moreforwards@???
>><<|pipecommand
>><</some/mailbox
>>---sender closes socket
>>
>>So the input is delimited with a LF, and the output by the the end of
>>the connection.
>>Or something more complex like this
>>
>>---exim opens socket (or uses a cached one)
>>
>>>>30 <---- this is the size of the data that follow
>>>>sometext
>>>>that goes over multiple lines
>>>>and should be as long as the first line indicates
>>>
>><<100 <----- responsesize
>><<100 chars of response
>>--- socket will NOT be closed
>
>
> I'd prefer something between the two of these, where output is
> terminated by something other than a socket close, but without having to
> handle response length validation.
>
> For example, you could use a double LF to terminate a response.
>
> That way, you still get to cache connections, but without worrying about
> the overhead of response length validation.
>
> I'd also recommend allowing for keep-alives. You could implement this
> easily by allowing the client to send an empty line (single LF), to
> which the server is expected to respond with a null response (double
> LF).
>
> All this assumes that responses never need to return sets of items in
> which one or more items may span multiple lines. Can you think of such
> a case? If so, you could still go the route I'm suggesting simply by
> picking another delimiter character.

I think the response length secures the thing a little bit, how do you
know that the response ended? Someone could kill the daemon while
sending the response, what you do? Using the lines that are send yet?
with my second solution you just can defer it.

Or some really strange thing, what if you want to use this to check for
vacation-messages? If the user added two LFs you either have to quote
them somehow or you will be dead ;)

I would prefer to provide both ways, the first one, so it acts like the
old iplookup-router and the response-size one for extended stuff.

Btw, your way will provide a little bit of CPU-overhead (but just a
LITTLE bit), because it would need to process everything char by char.

ciao