Looking for guidance on how best to use Boost ASIO in this scenario
I have the following scenario: Up to 1000 client users. 1 Server (or multiple instances of a server). The server(s) read a set of 5-15 incoming data feeds that update as often as 10 to 50 times per second. Each feed is updating at a different interval, as information comes in (essentially random). The server processes the data as it arrives from these feeds and when it finds a useful piece of information, it sends a message to some subset of the 1000 clients. The clients are not all interested in the same thing. It could be that each client has a different interest, and it could be that many times per second each client will need to be notified of that interest. That should be the worst case scenario, as meaningful changes in information probably won't require updates to the client that often, even though the 5-15 feeds are constantly updating. So what is the best way to structure this design using ASIO? Should the 1000 clients actually be set up as servers, and the server really just contact them by connecting each time there is an update that interest them? Or should the 1000 clients all connect with a permanent connection, polling for updates? Thanks for any advice.
Up to 1000 client users. 1 Server (or multiple instances of a server).
The server(s) read a set of 5-15 incoming data feeds that update as often as 10 to 50 times per second. Each feed is updating at a different interval, as information comes in (essentially random).
At the server side you can do some "load-balancing" using thread-per-cpu or io_service-per-cpu approach (see in the asio examples).
So what is the best way to structure this design using ASIO? Should the 1000 clients actually be set up as servers, and the server really just contact them by connecting each time there is an update that interest them?
Or should the 1000 clients all connect with a permanent connection, polling for updates?
I'm not sure about what you mean by saying "set up as server". Certainly, your client does not wait for incoming connections from the server, but initiates them. Once it connected to the server, it can send data with async_write, and at the same time it can issue async_read request - to wait for some data from the server. When the server sends you the data, the handler of async_read is invoked -- the client processes the data, and issues async_read again. This way the client can always be aware of an incoming data.
So what is the best way to structure this design using ASIO? Should the 1000 clients actually be set up as servers, and the server really just contact them by connecting each time there is an update that interest them?
Or should the 1000 clients all connect with a permanent connection, polling for updates?
I'm not sure about what you mean by saying "set up as server". Certainly, your client does not wait for incoming connections from the server, but initiates them. Once it connected to the server, it can send data with async_write, and at the same time it can issue async_read request - to wait for some data from the server. When the server sends you the data, the handler of async_read is invoked -- the client processes the data, and issues async_read again. This way the client can always be aware of an incoming data.
I see. The clients aren't going to be sending much of anything. They are mostly going to just be receiving data. Is there a particular sample that shows client/server with async_data read? Does this mean the client will be polling or will be notified when there is data to read? ________________________________ From: Igor R <boost.lists@gmail.com> To: boost-users@lists.boost.org Sent: Tuesday, March 24, 2009 1:52:19 PM Subject: Re: [Boost-users] Looking for guidance on how best to use Boost ASIO in this scenario
Up to 1000 client users. 1 Server (or multiple instances of a server).
The server(s) read a set of 5-15 incoming data feeds that update as often as 10 to 50 times per second. Each feed is updating at a different interval, as information comes in (essentially random).
At the server side you can do some "load-balancing" using thread-per-cpu or io_service-per-cpu approach (see in the asio examples).
So what is the best way to structure this design using ASIO? Should the 1000 clients actually be set up as servers, and the server really just contact them by connecting each time there is an update that interest them?
Or should the 1000 clients all connect with a permanent connection, polling for updates?
I'm not sure about what you mean by saying "set up as server". Certainly, your client does not wait for incoming connections from the server, but initiates them. Once it connected to the server, it can send data with async_write, and at the same time it can issue async_read request - to wait for some data from the server. When the server sends you the data, the handler of async_read is invoked -- the client processes the data, and issues async_read again. This way the client can always be aware of an incoming data.
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I see. The clients aren't going to be sending much of anything. They are mostly going to just be receiving data. Is there a particular sample that shows client/server with async_data read?
There're lots of examples that involve async. read/write: http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/examples.html The most simple is async.chat client: http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/example/chat/chat_c...
Does this mean the client will be polling or will be notified when there is data to read?
The handler that you pass to async_read is called by asio when the read operation is complete.
participants (2)
-
console shark -
Igor R