Re: [Linuxsampler-devel] Lates CVS commit

[Rui N. C. <rn...@rn...>]

Hi Christian,
>>
>> But you're right. It's not clear enough. I will fix that. That was an
>> implied assumption fault by me, because usually network protocols allow
>> this multi line behavior, because it doesn't make sense to establish a
>> new connection for every single network command.
>>
>
> It's not a question of just allowing multi-line/command or not, is also
> that "feature" that whether every command must be CRLF terminated.
>
> On my recent tests, your bison-based parser only recognizes a command if
> there's a CRLF terminator. If one's missing, you do nothing, don't even
> respond to a client that issues a single command but without terminating
> it with CRLF.
>
> It was this "undocumented" behaviour that I was referring to.
>

To make myslef a little bit more clear, about this behavioral issue:

Current linuxsampler server does NOT respond as soon as a valid syntax
command is received.

For example, when a client sends just "ADD CHANNEL", the server seems to
wait for an additional character before it responds.

If otherwise the client sends "ADD CHANNEL\n", the server recognizes the
command properly and responds right away. In fact, it ONLY responds when
any other character is present, not necessarily "\n".

Again, if a client only sends e.g. "GET CHANNELS" and nothing more, it
will hang forever for a reply that will never arrive. Think this is wrong.

My suggestion is either:

1) fix the server parser to reply immediately as soon a valid command is
detected, OR

2) make that LF/CR+LF command terminator officially part of the command
protocol, at least for client request strings.

I do prefer the first solution, as it complies by default with the current
LSCP document draft (rev.03), but can surely live with second if it's made
"official" :)

Please note that my complaint is not about whether the server can handle
more that one command in a batch or single tcp transaction. That's fine
with me, although liblscp was primarily designed with a
single-command-per-transaction semantics in mind.

Note that current liblscp does not make a new connection on each command.
It connect()'s, then for each command transaction a send() and recv()
sequence pair is performed. The session would be only close()'d when the
client is done.

OTHO, the problem with Vladimir's netcat test was that several commands
were being buffered and stuffed in one send(), for which the latest
liblscp patched linuxsampler version does not work -- my
LSCPServer::server_callback was designed to handle and parse only one
command buffer at a time. That can be changed of course. And I will try to
comply to it.

Chris, I'm willing to devel into your bison/yacc nightmare :) I'm still
insisting in patching liblscp into the linuxsampler server, but this time
using the bison based parser. Yes, I'm telling you that I can get rid of
my handcrafted-pseudo-parser but sticking with liblscp.

So, as a first timer, I wish to make liblscp's oriented
LSCPServer::server_callback() to pump all received data into your parser.
Note that this callback is called whenever the server recv()'s data from
the client. No translation is done to the data between recv() and the
callback. A session handle that uniquely identifies a client, is also
given on each callback, which shall be used when responding back to the
client, so it must be preserved along the whole parsing.

Now we've got an emerging problem: if we expect to have several clients
simultaneously, together with support for multi-line/command buffering, we
must preserve the parser state between each callback (or recv() for that
matter). That makes for the server maintaining a pool of parser instances,
one instance for each client connection and identified by an opaque
connection handle?

OK. Why I'm in insisting on liblscp? Mainly 'coz of reusability and it
already does multi-client, multi-threading and also because the UDP event
notification stuff is already there too: you have only to call
lscp_server_broadcast() when an change event pops up, liblscp takes care
of all the rest ;)

Hope to have made my position clear.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

P.S. Chris I'll try to be on IRC this afternoon and/or evening.