[Gambas-user] Problem with broadcasting UDP sockets - was Re: Problem with READ on a UDP socket

[Doriano Blengino]

Gareth Bult ha scritto:
> Urm,
>
> When you say doesn't scale .. exactly how many clients do you have and how quickly do they need to know about updates?
>
> Let's say for the sake of argument your SQL server can process 2000 moderate queries per second (not unreasonable) and you want to poll every second with 10 clients. This really isn't much of an overhead .. ???
>
> Bear in mind MySQL has a query cache .. if you go 100 seconds with no updates, 10 clients will make 1000 SQL requests, but these will be identical and the server will probably only have to do any real work once ... so ... ??
>   
> This for a 24 hour dinghy charity race that happens once a year.
>
> There are programs that put race data into a mysql database
> ("providers") and other programs that display the data in different ways
> ("users") depending on what audience is targeted.
> Ideally, there could be any number of providers and users on the same
> machine.
>
> How would a "user" know that new data is available? Traditionally, I had
> been polling the database but it does not scale very well, particularly
> if new data needs to be displayed fairly quickly.
>
> What I had done now is to have each provider (after changing data in the
> db) send a udp broadcast to the whole subnet saying "to whom it may
> concern, table x in db y has changed."  It does not need to know who the
> users are. Likewise, the users do not need to know who the providers
> are. All they need to know is where the database is.
>
> It is very simple and worked very well, except I could only have one
> user per machine.
>
> Ideas, anyone? Could database triggers do the job?
>
> Best Regards,
> Werner Dahn
>   
I agree with Gareth...

but assuming that you have many "tables x" in many "db y", you could 
make one more table in a common database, where to put log records in 
the form "datetime - table x in db y has been updated". Every user can 
then do a select on this single table, selecting on "datetime > 
last-time-I-readed-this-log".

Otherwise, as Benoit says, a single daemon listening in every machine 
could service many users. But it is not so simple to build a reliable 
system; if a broadcast packet fails to reach a machine, there is no easy 
way to know about. If broadcasts fire often (say, every 10 seconds), 
this could be not a problem. So, the database solution, if viable, is 
guaranteed to work.

Cheers,
Doriano