Subject: Re: [linux-audio-dev] LADSPA Plugin Uniqueness
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 18 2000 - 10:12:55 EST
On Sat, 18 Mar 2000, Richard W.E. Furse wrote:
> Solutions:
>
> (1) Just hope that plugin file names don't clash and that people would
> never rename plugins. (!)
Not very helpful, IMO. Also depends on what kind of names the file
system can handle, so it's hard to make it platform independent.
> (2) Have a centralised list of valid plugin file names, make it easy for
> people to register stuff there.
More complexity, and it still doesn't solve the problem when two
plugins will eventually have the same name...
> (3) Use centralised plugin-level ID allocation scheme, make it easy for
> people to register stuff there. Perhaps could use 24bits of plugin ID to
> give some space for hosts to merge these with their own ID schemes.
Probably the safest way to go, but it does require some practical
issues to be solved. Anyway, as opposed to VST, we don't have lots of
plugins using some other system, that will break if we go this way.
> Both (2) and (3) require a centralised list of what names & IDs have been
> allocated. (3) is very much my preference and I'm prepared to host it at
> least initially. Developers could email me and say how many IDs are needed
> and I can allocate a block. Other approaches include posting requests to
> the LAD list (annoying and still needs someone to collate) or automated
> allocation by web page (I'm a little worried about abuse with this).
I was thinking about this the other day...
If the IDs are big enough, and there is a sane limitation on how
many IDs you can get out of the server in a certain amount of time
(or something like that), it doesn't really matter if people start to
steal unique IDs for other things, or just try to break the system.
We're probably fine as long as the server cannot run out of IDs for
the next few hundred years or so. Anything less than 100 years is
inventing another y2k problem, though. This ID system may well migrate
to new API versions for quite a few years...
So, how about this?
* 32 bits for the developer ID, and 32 bits for the
developers to keep track of themselves. Allowing the
server to spit out up to 86400 IDs a day akes the
developer IDs last for some 126 years.
* The server should probably be a mail service, so that
you ask for a certain number of IDs, and get a reply
ASAP.
* The server should have a sensible restriction as to
how many IDs you can reserve in one transaction.
* Upon successfully sending a mail containing a number
of IDs, the server should refuse to deliver more IDs
to this address for a little while, in order to prevent
the simplest forms of abuse.
* Every ID request mail should be checksummed (preferably
one sum per line), and the checksum should be used for
blocking ackording to the same rules as for mail
addresses. (That is, an original .sig may give you your
IDs faster! ;-)
* There should be a timeout restriction for domains as
well (as some abusers may otherwise just fake lots of
addresses on some host that just sends all unknowns to
info or something). This restriction needs a shorter
timeout, as there could be quite a few legitimate users
on the same mail server.
* The restrictions above must be chosen so that it's
practically impossible for a few abusers to exhaust the
maximum IDs/day rate using any tricks possible within
the bandwidth of the server's connection.
* If the server is low on IDs according to the 86400/day
schedule, it should be more restrictive about releasing
large numbers of IDs in a single transaction, so that
legitimate users don't get blocked by abusers.
This might look like overkill, and perhaps it is, but there really
*are* people out there, who enjoy f*cking the work of others up, so
one can never be too careful... This is a thing that could impact a
lot of people if the API gets popular, so be assured that it'll be a
popular target.
BTW, I think this should be handled manually until someone offers
putting it on a server behind a decent firewall. It may mean more
trouble than the obvious if it should be cracked...
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Mar 19 2000 - 01:33:22 EST