iiwusynth-devel
[Top][All Lists]
Advanced

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

[iiwusynth-devel] Command response framing and TCP/IP


From: Ken Ellinwood
Subject: [iiwusynth-devel] Command response framing and TCP/IP
Date: Thu, 19 Dec 2002 10:20:08 -0800 (PST)

My vote is to keep things as simple as possible.  I feel that transaction
numbering only make sense if we expect the command interpreter to be
multi-threaded (i.e., being capable of processing multiple, simulataneous
outstanding requests).  I've always assumed that the command interpreter will
operate like a FIFO.  Also, prepending a transaction number makes it harder on
the client to parse the responses.   Over TCP/IP I think the command processor
should not echo the commands, just the responses, and provide a simple one line
delimiter for marking the boundaries between command responses (delimiter
configurable via a "set" command, of course).

I'm well on my way developing a simple TCP/IP command server which will support
one client connection at a time.  I had it working on Linux using fgets() after
converting the client's socket descritpor to a FILE* using fdopen().  Then I
found that fdopen() doesn't work on socket descriptors under Windows (nor do
read() or write()).  So now I'm reworking the code to use select(), recvfrom()
and send().  The consequence of this is that rather than pass a FILE* to the
command handlers, they must continue to return output in the reply buffer
(which some currently dont, i.e., "inst").  But what if the reply is longer
than 1K? -- the current size of the reply buffer.  I'm thinking now that the
command handlers should get "char** reply", and "int* reply_len", allocate the
reply buffer themselves to ensure that the buffer is the correct size, and by
contract, have each command interpreter loop free the buffer after writing the
reply to the correct destination.

> On the GUI side, there is a function 'command_to_synth', that has two
> arguments: Command and callback.
> It invents a transaction number, sends the command to the synth like
> shown, stores all the output between #start_transaction and
> #end_transaction in a list and calls the callback function with the
> list. It works fine.
> Real-time messages like 'noteon' or 'cc' have to be filtered, though.
> 
> One improvement on this scheme might be to have the TCP/IP module add
> the transaction number to each line of output. As in
> #start_transaction 43
> inst 0
> 43: 0: Mightbeasoundfont.sf2
> #end_transaction 43
> 
> Also, there could be a dedicated 'echo' command instead of the comment.
> But this is just the solution I came up with when working on my GUI,
> there may be better or more established ways of tackling the problem.
> 
> Cheers
> 
> Markus
> 
> 
> 
> 
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/iiwusynth-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]