Re: [Linuxsampler-devel] LinuxSampler API

[Christian S. <chr...@ep...>]

Es geschah am Sonntag, 28. Dezember 2003 14:16 als David Olofson schrieb:
> Well, I haven't used D-BUS, but it seems to me that for one library to
> talk to one daemon/engine, it's almost overkill to use even the POSIX
> IPC stuff. All we need is a simple binary or ASCII protocol that can
> be piped through pipes, TCP/IP, UDP (needs an extra protocol layer),
> shared memory, lock-free FIFOs or whatever. (Check out FluidSynth to
> get an idea of what I have in mind.)

Ok, Benno also had a protocol in mind instead of a C API. The point using an 
API on programming language level is that the frontend developer will get an 
error at compile time when the API has changed whereas if using a protocol it 
will result in runtime errors that are sometimes not obvious and finally 
elaborating a C based API is easier than a protocol based one; it just needs 
to write a C header file and respective API documenation.
But ok, if nobody raises an objection, then we'll design an ASCII protocol 
instead. That has of course the advantage that developers can even write 
frontends in C foreign languages (e.g. Java).

I discussed a bit with Benno on IRC today and so I would make the following 
proposal for the communication method:

The frontend connects itself via TCP to the sampler engine. When the frontend 
connects it must choose between two possible communcation methods:

	1) Polling
	It's up to the frontend's responsibility to periodically "poll" the engine
	for changes. That's very simple to implement but has the disadvantage of
	traffic overhead and of course latency issues, but is mostly sufficient.

	2) Notification
	The frontend will be notified on a second "connection" based on UDP by the
	engine whenever a (for the frontend interesting) event occured. As the size
	limit of UDP packets is constrained to < 65kB the engine only sends a
	"notify" message that something has changed and the category this 
	notification refers to. The frontend will then react on that event by
	requesting the detailed change on it's normal TCP connection. Here an
	example:

		The engine wants to inform the frontend(s) that the fill status of the
		currently active disk streams' buffers have changed. The engine will then
		send an UDP package to all registered frontends that want to by notified
		which will look like that: "DISKSTREAM_BUFFER_FILLSTATE CHANGE"
		That's all.
		After that the frontend will react on the notify UDP packet by requesting 
		the current fill state of	all disk stream buffers on it's primary TCP
		connection: "GET DISKSTREAM_BUFFER_FILLSTATE ALL" and the engine will
		response by sending all fill states: "[1]=98%,[2]=83%,[3]=75%,..."
	
That way it's up to the frontend's developer if he's willing to implement the 
bidirectional communication approach or not and we don't have to implement 
our own session layer for the UDP protocol.

Thoughts? Suggestions?

If there are no objections I will write an initial RFC document for the 
protocol so we can elaborate the detailed shape of the protocol here on the 
list. 

CU
Christian