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

Gareth Bult gareth at ...1689...
Wed Nov 5 13:19:24 CET 2008


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 ... ??

Gareth.

----- Original Message -----
From: "Werner" <wdahn at ...1000...>
To: gambas-user at lists.sourceforge.net
Sent: Wednesday, 5 November, 2008 10:32:34 AM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [Gambas-user] Problem with broadcasting UDP sockets - was Re: Problem with READ on a UDP socket

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





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gambas-user mailing list
Gambas-user at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user

-- 
Managing Director, Encryptec Limited
Tel: 0845 5082719, Mob: 0785 3305393
Email: gareth at ...1689... 
Statements made are at all times subject to Encryptec's Terms and Conditions of Business, which are available upon request.




More information about the User mailing list