Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You need to decide first which style of socket communication you are going to use:</p> <ol> <li><p>synchronous - means that all low-level operations are blocking, and typically you need a thread for the accept, and then threads (read thread or io_service) to handle each client.</p></li> <li><p>asynchronous - means that all low-level operations are non-blocking, and here you only need a single thread (io_service), and you need to be able to handle callbacks when certain things happen (i.e. accepts, partial writes, result of reads etc.)</p></li> </ol> <p>Advantage of approach 1 is that it's a lot simpler to code (??) than 2, however I find that 2 is most flexible, and in fact with 2, by default you have a single threaded application (internally the event callbacks are done in a separate thread to the main dispatching thread), downside of 2 of course is that your processing delay hits the next read/write operations... Of course you can make multi-threaded applications with approach 2, but not vice-versa (i.e. single threaded with 1) - hence the flexibility...</p> <p>So, fundamentally, it all depends on the selection of style...</p> <p><strong>EDIT:</strong> updated for the new information, this is quite long, I can't be bothered to write the code, there is plenty in the boost docs, I'll simply describe what is happening for your benefit...</p> <p>[main thread] - declare an instance of io_service - for each of the servers you are connecting to (I'm assuming that this information is available at start), create a class (say <code>ServerConnection</code>), and in this class, create a tcp::socket using the same io_service instance from above, and in the constructor itself, call <code>async_connect</code>, NOTE: this call is a scheduling a request for connect rather than the real connection operation (this doesn't happen till later) - once all the <code>ServerConnection</code> objects (and their respective async_connects queued up), call <code>run()</code> on the instance of io_service. Now the main thread is blocked dispatching events in the io_service queue.</p> <p>[asio thread] io_service by default has a thread in which scheduled events are invoked, you don't control this thread, and to implement a "multi-threaded" program, you can increase the number of threads that the io_service uses, but for the moment stick with one, it will make your life simple...</p> <p>asio will invoke methods in your ServerConnection class depending on which events are ready from the scheduled list. The first event you queued up (before calling run()) was <code>async_connect</code>, now asio will call you back when a connection is established to a server, typically, you will implement a <code>handle_connect</code> method which will get called (you pass the method in to the <code>async_connect</code> call). On <code>handle_connect</code>, all you have to do is schedule the next request - in this case, you want to read some data (potentially from this socket), so you call <code>async_read_some</code> and pass in a function to be notified when there is data. Once done, then the main asio dispatch thread will continue dispatching other events which are ready (this could be the other connect requests or even the <code>async_read_some</code> requests that you added).</p> <p>Let's say you get called because there is some data on one of the server sockets, this is passed to you via your handler for <code>async_read_some</code> - you can then process this data, do as you need to, but and this is the most important bit - once done, schedule the next <code>async_read_some</code>, this way asio will deliver more data as it becomes available. VERY IMPORTANT NOTE: if you no longer schedule any requests (i.e. exit from the handler without queueing), then the io_service will run out of events to dispatch, and run() (which you called in the main thread) will end.</p> <p>Now, as for writing, this is slightly trickier. If all your writes are done as part of the handling of data from a read call (i.e. in the asio thread), then you don't need to worry about locking (unless your io_service has multiple threads), else in your write method, append the data to a buffer, and schedule an <code>async_write_some</code> request (with a write_handler that will get called when the buffer is written, either partially or completely). When asio handles this request, it will invoke your handler once the data is written and you have the option of calling <code>async_write_some</code> again if there is more data left in the buffer or if none, you don't have to bother scheduling a write. At this point, I will mention one technique, consider double buffering - I'll leave it at that. If you have a completely different thread that is outside of the io_service and you want to write, you must call the <code>io_service::post</code> method and pass in a method to execute (in your <code>ServerConnection</code> class) along with the data, the io_service will then invoke this method when it can, and within that method, you can then buffer the data and optionally call <code>async_write_some</code> if a write is currently <em>not in progress</em>.</p> <p>Now there is one VERY important thing that you must be careful about, <strong>you must NEVER schedule</strong> <code>async_read_some</code> or <code>async_write_some</code> if there is <strong>already one in progress</strong>, i.e. let's say you called <code>async_read_some</code> on a socket, until this event is invoked by asio, you must not schedule another <code>async_read_some</code>, else you'll have lots of crap in your buffers!</p> <p>A good starting point is the asio chat server/client that you find in the boost docs, it shows how the async_xxx methods are used. And keep this in mind, all async_xxx calls return immediately (within some tens of microseconds), so there are no <strong>blocking</strong> operations, it all happens asynchronously. <a href="http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/chat/chat_client.cpp" rel="noreferrer">http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/chat/chat_client.cpp</a>, is the example I was referring to. </p> <p>Now if you find that performance of this mechanism is too slow and you want to have threading, all you need to do is increase the number of threads that are available to the main io_service and implement the appropriate locking in your read/write methods in ServerConnection and you're done. </p>
    singulars
    1. This table or related slice is empty.
    1. POusing boost sockets, do I need only one io_service?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNim
    1. USNim
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COyea ok what i dont get is this: i want to make a thread for always receiving and my "main thread" would sometimes send packets.. so I'll have to use the same socket for both operations, but the problem is i see it is not thread-safe to do so in this why.. so what should i do?
      singulars
      1. PO
      1. USgrich
    2. COTry not to think interms of threads, instead, update the above question with what it is you are intending to do, how do you want this server to work? May be easier to answer then...
      singulars
      1. PO
      1. USNim
    3. COI'm not doing a sever, I'm doing a client that connects to a-lot of servers. Anyways i edited my question to clarify everything better, Tnx.
      singulars
      1. PO
      1. USgrich
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload