> 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