I'm writing a program with sockets and I need QoS services so I'm using qWAVE. Now I want to be able to detect network changes and adapt to it, so based on documentations I should use QOSNotifyFlow. While its design is great for one or 2 sockets, when you have multiple sockets that each one(group) of them have different characteristics, so added to different flow, you can't use OVERLAPPED structure easily(WaitForMultipleObjects... have a hard coded limitation).
So I was searching for an alternative way that does not use waiting for the overlapped event to signalled and I found this question that ask a similar question and an MSFT answer him that he may use an IO completion port.
Now my question is can I use something like IO completion port with this kind of functions that get an OVERLAPPED structure?
Related
Can anyone recommend an elegant and efficient framework to craft a main event loop in C++ where I need to do the following:
Handle keyboard input
Check for incoming datagrams on a socket
Queue and send outgoing reply datagrams
Manage curses-based windowing
I'm familiar with Cocoa mostly, and all of that functionality is conveniently wrapped into the core classes. For portability, and to knock off some rust, I chose C++ to write this network-client app based on curses (for that sporty IRC/terminal look). Yes, I'm a glutton for punishment.
Would an observer pattern work? Perhaps setting up a global notification center to register for and receive messages? Should the network part run on it's own thread? The goal is to produce a version for unix, linux and windows at some point, so portability is the focus.
Any recommendations on classes for any of this would be helpful. I'm looking at ZMQ for handling the networking, but I'm not sure it'll handle UDP datagram service.
Looking for the best approach to sending the same message to multiple destinations using TCP/IP sockets. I'm working with an existing VS 2010 C++ application on Windows. Hoping to use a standard library/design pattern approach that has many of the complexities already worked out if possible.
Here's one approach I'm thinking about.. One main thread retrieves messages from a database and adds them to some sort of thread safe queue. The application also has one thread for each client socket connection to some destination server. Each one of these threads would read from the thread safe queue, and send the message over a tcp/ip socket.
There may be better/simpler/more robust approaches than this one though..
The issues I have to be concerned about mostly are latency. The destinations could be anywhere, and there may be significant latency between one socket connection and another.
The messages must go in an exact FIFO order to all the destinations.
Also one destination will be considered the primary destination.. all messages must get to this destination, no exceptions. For the other destinations, i.e. non-primary, the messages are just copies and it's not absolutely critical if the non-primary destinations do not receive a few messages. At any point, one of the non-primary destinations could become the primary destination. If one of the destinations falls too far behind, then that thread would need to catch up to the primary destination, but skipping some messages.
Looking for any suggestions. Preliminary research so far, my situation appears to be something akin to a single producer and multiple consumers pattern, or possibly master-worker pattern in Java.
I need to implement this in C++ on Windows, and the application must use tcp/ip sockets using an existing defined protocol.
Any help at all would be greatly appreciated.
You need exactly two threads, one that saturates the IO channel to the database and another that saturates the IO channel to the network leading to the 12 servers. Unless you have multiple network interfaces (which you should think about!) you don't send things faster by using multiple threads. Also, since you don't have multiple threads taking care of the network, you don't have to sync them.
What you definitely need to know about is select(). In the case of WinSock, also take a look at WSAEventSelect/WaitForMultipleObjects. Basically, you take a message from the queue and then send it to all clients when they're ready. select() tells you when one of a set of sockets is ready to accept data, so you don't waste time waiting or block trying to send data. What you need to come up with is a schema to reconnect after broken connections, when to drop messages to lagging clients etc. Also, in case the throughput to the different targets varies a lot, you need to think about handling multiple messages in parallel. If they are small (less than a network packet's payload) it makes sense combining them anyway to avoid overhead.
I hope this short overview helps getting you started, otherwise I can elaborate on the details.
The native C socket API returns on accept() a new socket descriptor, which is bound to a certain remote socket. That's good because I can create a thread, pass the socket and establish a point-to-point, or better a thread-to-thread connection over the internet. And that's exactly what I want: one thread from the client should be connected to a destined thread on the server. Hence I dont need a workerpool or loadbalancing not even async operation. The server threads save history. ZeroMQ seems great but as far as I understood it does not split up sockets on accept.
Is there a way to establish such an synchronous thread-to-thread connection with ZerMQ?
You're asking how to replicate a particular solution (handing off a socket to a thread) to a broader problem (how to write scalable servers).
The 'one thread per socket' design only works in one pattern which is request-reply, e.g. HTTP. Whereas the really high volume use cases are for data distribution (publish-subscribe), or task distribution (pipeline). Neither fit a 1-to-1 model.
It is a common error when you learn a new tool to ask, "how does this tool do what my old tools do" but you won't get good results like that. Instead, take the time to actually learn how the tool works, and then use that knowledge to re-think your problems and the best solutions for them.
I thought Zmq handle this multi connection for you; I prefer to create a thread-to-thread communication by handling connection within thread callback function, This mean my main zmq connection created in separate thread; which can make separate connection control within threads.
I have been reading through the boost asio documentation for a couple of hours now, and while I think the documentation is really great, I am still left a bit confused on how to implement the system that I need.
I have to stream info, from a game engine, to a list of computers over tcp. One snag is that, unlike traditional pub/sub, the computer that does the distribution of info is actually the computer that has to connect to the subscribers as well (instead of the subscribers registering with the publisher). This is done via a config file - a list of ip's/ports along with the data that they each require. The subscribers listen, but do not know the ip of the publisher. (As a side note, I'm quite new to network programming, so maybe I'm missing something .. but it's strange that I do not find much information regarding this style of "inverted" client-server model..)
I am looking for suggestions for the implementation of such a system using boost asio. Of course I have to integrate the networking into an already existing engine, so with regards to that:
What would be a good way to handle messages being sent to multiple computers every frame? Use async_write, call io_service.run and then reset every frame? Would having io_service.run have its own thread be better? Or should I just use threads and use blocking writes?
I found a thread which deals with part of my question: using io_service within a game loop -Boost::Asio : io_service.run() vs poll() or how do I integrate boost::asio in mainloop. I will try a few things and post a more definite answer if I do find a good solution.
I'm writing a daemon that needs to both run in the background and take care of tasks and also receive input directly from a frontend. I've been attempting to use sockets to take care of this task, however, I can't get it to work properly since sockets pause the program while waiting for a connection. Is there anyway to get around this?
I'm using the socket wrappers provided at http://linuxgazette.net/issue74/tougher.html
Thank you for any and all help
You will need to use threads to make the socket operations asynchronous. Or use some library that has already implemented it, one of the top ones is Boost Asio.
There are a few ways to handle this problem. This most common is using an event loop and something like libevent. Then you use non-blocking sockets.
Doing this in an event driven fashion can require a big shift in your program logic. But doing it with threads has its own complexities and isn't clearly a better choice.
Usually the daemons use event loops to avoid the problem of waiting for events.
It's the smartest solution to the problem that you present (do not wait to an asynchronous event). รง
Althought, usually the entire daemon is build over the event loop and it's callback architecture, and can cause a partial rewritting, so usually the quick and dirty solution is creating a separate thread to handle those events wich usually creates more bugs than it solves. So, use an event loop:
libevent.
glib event loop.
libev.
boost::asio
...
From your description, you have already divided your application into a frontend (receiving input) and backend (socket handling and tasks). If the input from the frontend is sent over the socket (via the backend) rather receiving input from the socket then it seems like you are describing a client and not a server. Client programs are typically not implemented as daemons.
You have created a blocking socket and need to either monitor in a separate thread execution a thread or even separate process) or make a non-blocking socket and poll frequently for updates.
The link to the LinuxGazette is a basic intro to network programming. If you would like a little more depth then take a look at Beej's Guide to Network Programming where the various API calls available to you are explained in a little detail.. and will, perhaps, make you appreciate more wrapper libraries such as Boost::ASIO.
Can be worth retaining control of the event loop yourself - its no complicated and provides flexibility down the track.
"C++ pseudo-code" for an event loop.
while (!done)
{
bool workDone = false;
// Loop over each event source or internal worker
for each module
{
// If it has work to do, do some.
if (module.hasWorkDoTo())
{
// Generally, do as little work as possible; e.g. process a single event for this module.
// But tinker with this to manage priorities if need be.
// E.g. Maybe allow the GUI to flush its queue.
module.doSomeWork();
workDone = true;
}
}
if (!workDone)
{
// System idle. No Sleep for a bit so we have benign idle baheviour.
nanosleep(...);
}
}