Unless you want to make a udp server, there is no such thing as a broadcast
in the tcp world, so you need to cycle though all your connections.
with as little as max 50 connections, you should be able to do this with
out having more than 2 threads, one for the listener and one for
connections.
Since all the connections can be stored in a single tlist (which you use to
send to group can read as well) you can easily loop though it and send you
messages out in minimal time, with no looking needed as all connection
related stuff is done in a single thread.
If you have very large messages and slow connections, you might want to
thread it.. with 50 connection you should be able to dedicate a thread to
each connection and simply send a threadmessages to each thread with the
data to be sent and let the thread completely manage the connection. again
no locks required until you need to do this with thread pools and manage the
connection externally from the worker threads.
51 threads in an application is not a large overhead for context switching,
so if that is a hard maximum, I see no need to make thread pools etc. unless
you do it as an exercise or want future scalability.
If you want to write it in a plattform indepentent way I suggest you
implement you own message queuing rather than using windows threadmessages,
but it's not required if this is a windows only application.
Mikael
On 8/26/07, Dennis Nielsen <[EMAIL PROTECTED]> wrote:
>
> Hi Mikael Ostensson, thank you for the reply.
>
> What you say sound very promising, but of cause it requires a lot of
> thread work.
> Well the latency should be as low as possible, without server using too
> much energy.
> I can see how the groupcanread call would help me receive information
> from a lot of client connections. But what would help do a broadcast,
> without doing a loop in a locked client list?
> Could this be done with a sendmessage api, and check for this message
> within every thread? Or is that a wrong approach to this problem?
> Broadcasting data is my biggest concern right now, and I would like to
> hear from anyone with experience in doing that (a good way).
>
> Regards Dennis
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> synalist-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/synalist-public
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
