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

[Benoit Minisini]

On mercredi 5 novembre 2008, Werner wrote:
> Doriano Blengino wrote:
> > Werner ha scritto:
> >> Benoit Minisini wrote:
> >>> On mardi 4 novembre 2008, Werner wrote:
> >>>> also, receiving udp broadcasts works only for one application. Any
> >>>> additional gambas application on the same machine throws
> >>>> a "Cannot bind to that socket" error.
> >>>>
> >>>> Best Regards
> >>>> Werner
> >>>
> >>> Can you provide a little example that shows the problem?
> >>
> >> will do, but it might take a week or two. Obviously, more than one
> >> computer is needed and I'm a bit short right now.
> >
> > The behaviour of "cannot bind to that socket" could be correct. On a
> > single machine there can be only one process listening on a given port.
> > So, if an application binds to a port, no other applications (neither
> > another instance of the same) can bind to that port again.
> > This can be possible if the machine has more than one interface, say
> > "127.0.0.1" and "192.168.1.1". Then two programs can listen on the same
> > port, but on different interfaces.
>
> Thanks for the clarification. What I had been doing is indeed as you
> describe it: trying on listen on the same port of the same interface
> more than once.
>
> Maybe I should explain what I have been up to; maybe someone can come up
> with a better concept.
>
> 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
>

Maybe you can make a little program that just listen to the socket, and then 
warn all others programs on the same machine (you can use a file for that).

Regards,

-- 
Benoit Minisini