[Devel] MI protocol enhancement

[Bogdan-Andrei Iancu]

Hi Dan,

the issues you are referring are not directly related to the MI 
interface, but to the modules implementing transports for it (like fifo, 
unixsock, xmlrpc, etc).

so, the syntax part is managed by the transport modules and can be 
different from transport to transport.

as yo said, for FIFO it is not an issue as it a stream like connection - 
you read until the other party closes the connection.

we will consider this aspects when we will develop new module, 
especially the one oriented on DATAGRAM communication.

regards,
bogdan

Dan Pascu wrote:

>I do not know if this thing was already considered for the new management 
>interfaces, but I'd like to raise one issue the current FIFO/UNIX socket 
>interfaces have.
>
>A command always ends with 2 LF characters, which is good as it allows 
>openser to know when one command ends and when the next starts.
>However the replies sent by openser do not follow the same guidelines and 
>they only have 1 LF character after the last line in the reply. As a 
>result if the reply is bigger than the MTU for the transport in 
>discussion, the response will not be returned with a single read 
>operation. At this point it will be uncertain if there is more to come or 
>not. Since the MTU may be unknown, it is very difficult to figure out if 
>I should stop reading because I already have all the answer or I need to 
>keep reading because there is more.
>
>Now on the FIFO interface this can be worked around, as one can read until 
>the reads return nothing (because openser will close the reply fifo after 
>it finishes sending). But the same is not true for the UNIX socket 
>interface given it is using SOCK_DGRAM and is never closed after a reply 
>is sent. But the FIFO interface has its own drawbacks (like the fifo may 
>block when being opened if there is none listening on the other end).
>
>To avoid all these issues, I want to propose to change the communication 
>protocol to also end a reply with the same 2 LF characters, so it will be 
>easy to determine where a reply ends without having to worry about the 
>MTU of the transport layer, or the type of interface used (FIFO, UNIX 
>socket, ...)
>
>  
>