suggestion on a simple server

hi, This is my first post to this group I don't know if it the right
place to post this question
if I'm making a mistake lead me to the correct group where to post.

I have to write a server whom target is play audio files. The Clients
connects to the server
trought the net and sends an id of the kind of sound to play, if the
server recognize the id play the associated sound. With the Ids I can
decouple the audio file from the logical sound.
My fear is about the ID becouse I think is important have a limited
number of this id. I mean, in my problem, a client can define custum
ids and configure it properly on the server. this, after a while,
could lead to have a lot of unused ids...
what do you think about this solution? any suggestion?

news75

Responding to News75...

> hi, This is my first post to this group I don't know if it the right
> place to post this question
> if I'm making a mistake lead me to the correct group where to post.
>
> I have to write a server whom target is play audio files. The Clients
> connects to the server
> trought the net and sends an id of the kind of sound to play, if the
> server recognize the id play the associated sound. With the Ids I can
> decouple the audio file from the logical sound.
> My fear is about the ID becouse I think is important have a limited
> number of this id. I mean, in my problem, a client can define custum
> ids and configure it properly on the server. this, after a while,
> could lead to have a lot of unused ids...
> what do you think about this solution? any suggestion?

I am confused about what this ID is identifying. It seems to identify a
particular audio file to be played. But, if so, then I would expect
there to be exactly as many IDs as there are unique audio files. So I
don't understand why the IDs are limited and how they would be customized.

Nor do I understand how an ID becomes "unused". I would expect that to
happen only if the audio file were removed from being available for
play, in which case I would expect the corresponding ID to be removed
from the relevant lookup table.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Jul 29, 8:21*pm, "H. S. Lahman" <h...@pathfindermda.com> wrote:
> Responding to News75...

> I am confused about what this ID is identifying.

ID identifies a kind of event. When on a client is triggered the
event, the client send a message with inside the ID of the event.
I would like identify and define a base set of IDs/events and all the
client have to use the
same set of ID because I believe the same event have to have the same
sound.
On the other hand I would like have the ability to define custom IDs
because I can't predict
everything but I would like avoid to define two IDs for the same
logical event. this is the real problem!
Other teams could implement their own client and introduce news ID
without verify if that event
had an ID already defined, this could lead to have a lot of ID for the
same event. I don't like this
and this could slow down the server.

Responding to News75...

>> I am confused about what this ID is identifying.
>
> ID identifies a kind of event. When on a client is triggered the
> event, the client send a message with inside the ID of the event.

OK, the ID is for an event on the client side, not <directly> a sound.
For a given client there is a 1:1 correspondence between IDs and events.

> I would like identify and define a base set of IDs/events and all the
> client have to use the
> same set of ID because I believe the same event have to have the same
> sound.

OK, the server needs to map the ID to a particular sound. Presumably the
server has a fixed number of sounds available.

> On the other hand I would like have the ability to define custom IDs
> because I can't predict
> everything but I would like avoid to define two IDs for the same
> logical event. this is the real problem!
> Other teams could implement their own client and introduce news ID
> without verify if that event
> had an ID already defined, this could lead to have a lot of ID for the
> same event. I don't like this
> and this could slow down the server.

OK, here you have to make an architectural decision. Is the sound mapped
to the event or to the ID? For example, could client A assign ID 'x' to
a different event than client B expecting the get the same sound that
client B gets for that ID?

I am beginning to suspect that you actually need two sets of IDs, one
for the event on the client side and one for the sound on the server
side. The customization then becomes defining which event ID goes with
each sound ID in a particular client. IOW, there is an ID-to-ID lookup
table in the client.

The sound IDs would be fixed based on whatever sounds are currently
available on the server. Then each client can have arbitrary events and
assign them arbitrary IDs. Once that is done, the mapping of event ID to
sound ID is done. When actually communicating with the server, one would
provide the sound ID obtained via table lookup from the mapping table
indexed by event ID.

If sounds can be added and removed from the server, then one needs to
notify the clients that their ID-to-ID mapping table needs to be
updated. That implies that one needs some sort of client registration
with the server. (Of course it could be done as part of the startup when
a client opens a link to the server.)


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

news75 escribió:
> On Jul 29, 8:21 pm, "H. S. Lahman" <h...@pathfindermda.com> wrote:
>> Responding to News75...
>
>> I am confused about what this ID is identifying.
>
> ID identifies a kind of event. When on a client is triggered the
> event, the client send a message with inside the ID of the event.
> I would like identify and define a base set of IDs/events and all the
> client have to use the
> same set of ID because I believe the same event have to have the same
> sound.
This sounds like you want to keep the id's server sided. A long integer
in java for instance will be enough to store all sounds you will ever
need. Consider using a database server sided and leave the unique id
creation to the database.
A possible database model would be:
UID (int), soundtag (varchar), filename (varchar), creation(timestamp)

with this small table you can store references between id and files and
name them independently. you can offer updates with new sounds to the
client based on the timestamp (you mght keep the date from the last update)

> On the other hand I would like have the ability to define custom IDs
> because I can't predict
> everything but I would like avoid to define two IDs for the same
> logical event. this is the real problem!
> Other teams could implement their own client and introduce news ID
> without verify if that event
> had an ID already defined, this could lead to have a lot of ID for the
> same event. I don't like this
> and this could slow down the server.
You can prevent this database sided with constraints. The database
decides on the unique id, so you woon't have any doubles, on the other
hand you can search for tags or filenames too.


Would this simple architecture serve your purposes?

regards,
Stefan Nolde

Wow, thanks for the suggestions!

>
> OK, here you have to make an architectural decision. Is the sound mapped
> to the event or to the ID?

Ok, I would like the sound was mapped on the event. same event same
sound.
I could do an analysis tool if different IDs are mapped on the same
sound could be used
the same ID. So after this analysis I can warn the team and say them
to use the correct ID...

>For example, could client A assign ID 'x' to
> a different event than client B expecting the get the same sound that
> client B gets for that ID?

could be happen...

> I am beginning to suspect that you actually need two sets of IDs

The idea of two kinds of IDs is good but I would like to explain a
little bit better my initial idea.

when a client get connected with the server it gives the list of the
IDs it knows.
The server check if it knows all the IDs, if not, it sends back an
answer with the list of the unknown IDs.
Now the client can send configuration commands to bind the new IDs
with an audio file chose from a
list of audio files known from the server.
After the initial configuration the server knows all the IDs of the
clients...
I think that in this context It is not necessary define the event IDs
and the sound IDs
because this is a good solution if the server has a fixed amount of
audio files but, in my idea,
I can add, in configuration phase, all the audio files I want...but I
could verify that any defined ID have a different audio file...
what do you think about this solution !?

On 30 Lug, 23:13, Stefan Nolde <stefan.no...@lazos.cl> wrote:
>
> This sounds like you want to keep the id's server sided. A long integer
> in java for instance will be enough to store all sounds you will ever
> need. Consider using a database server sided and leave the unique id
> creation to the database.
> A possible database model would be:
> UID (int), soundtag (varchar), filename (varchar), creation(timestamp)
>

What is it soundtag ?!

Responding to News75...

> when a client get connected with the server it gives the list of the
> IDs it knows.
> The server check if it knows all the IDs, if not, it sends back an
> answer with the list of the unknown IDs.
> Now the client can send configuration commands to bind the new IDs
> with an audio file chose from a
> list of audio files known from the server.
> After the initial configuration the server knows all the IDs of the
> clients...

A possible problem with this is one you already mentioned. If clients go
away permanently, then the server is left keeping track of a bunch of
IDs that are "unused".

Also, if each client can provide its own IDs, the server can have
multiple IDs for each audio file. If there are a lot of clients, that
can get messy.

> I think that in this context It is not necessary define the event IDs
> and the sound IDs
> because this is a good solution if the server has a fixed amount of
> audio files but, in my idea,
> I can add, in configuration phase, all the audio files I want...but I
> could verify that any defined ID have a different audio file...
> what do you think about this solution !?

You always have to provide some sort of ID to the server to select an
audio file for play. I think that should be the unique ID that the
server associates with each audio file. The server doesn't care why a
client wants a particular audio file played or how many different
clients there are, so the mapping to client events is a personal matter
for the clients. IOW, the server just needs to understand what audio
files it has and how they are uniquely identified.

If audio files are being added/removed, I still think the mapping of
events to audio files should be on the client side (i.e., a pull model).
[The client is obviously not "thin" because it is doing something that
raises events. In addition it is already in "pull" mode because to
requests audio file play.] As you indicate, the server still has to
provide a list of available audio files when the ID is not known so that
doesn't change.

When the client links to the server the first time, it can obtain a list
of current audio file IDs from the server. Similarly, if the client
subsequently adds an event, it can obtain the current list. Once the
client has the list of available audio files it can map its events to
those audio file IDs any way it wants. (I assumed an event ID would be
convenient, but it really isn't necessary so long as the client can
distinguish between events when doing the mapping.) The client can then
save the mapping of events to audio file IDs as configuration data
(e.g., a .ini file for its own startup).

Basically the same mechanism can be used if the server adds/removes
audio files. When a client establishes a link it can provide a date
stamp and ask if there were changes. The server can tell the client the
list has changed since the date stamp and if the client cares, it can
obtain the list and update its mappings pretty much as if it were
linking in for the first time.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

great! I have to think your solution over...

But I think the two solution are quite similar...
An important thing I have learned is that is need that each audio
files must be mapped with only one ID. In this way I can mantain a
limited number of ID. then the client have to map his events with the
appropriate server ID. The client can add a new ID on the server but
get an error if it try to bound the ID with an audio file alredy in
use.

Mapping the audio file on an unique ID is important also because keep
sound-event consistency and force the clients configurator to find out
the relation between sound and event.

news75 escribió:
> On 30 Lug, 23:13, Stefan Nolde <stefan.no...@lazos.cl> wrote:
>> This sounds like you want to keep the id's server sided. A long integer
>> in java for instance will be enough to store all sounds you will ever
>> need. Consider using a database server sided and leave the unique id
>> creation to the database.
>> A possible database model would be:
>> UID (int), soundtag (varchar), filename (varchar), creation(timestamp)
>>
>
> What is it soundtag ?!
the sound tag would be a simple alias (name) for the sound. preferably
descriptive, not nescessarily unique (though that would help users in
identifying a sound they look for)

regards,
Stefan