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

[Werner]

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