I write portable Windows/Linux application that uses sockets. I use gethostbyname function to perform DNS lookups.
However, I don't see how to set gethostbyname timeout and secure my application against hanging during name lookup.
Of course, it is possible to run gethostbyname on another thread, and that what I do. However, it is solution for trivial applications only.
My application uses 1000-3000 connections in parallel. In such situation the question is: what to do with timeouted threads? I don't see good solution. We can "forget" them, however, we are at risk that our program threads count will grow up to infinity on bad networks. We can terminate them, but the idea looks terrible. From my experience, Windows can crash after thousands of threads termination, and I don't know how Linux will behave in such conditions.
Also, thread creation needs many resources; it is not good idea to create 3000 threads just to run gethostbyname function and exit.
So, separate thread doesn't look like good idea for really complex application. Another alternative is to write own DNS client of course, however, it also doesn't look good.
Is there any "official" way on Windows and Linux (or better portable way) to get host address with custom timeout?
First of all: don't use gethostbyname(), it's obsolete. Use getaddrinfo() instead.
What you want is asynchronous name resolution. It's a common requirement, but unfortunately there is no "standard" way, how to do it. Here my hints for finding the best solution for you:
Don't implement a DNS client. Name resolution is more than just DNS. Think of mDNS, hosts files and so on. Use a system function like getaddrinfo() that abstracts the different name resolution mechanisms for you.
Some systems offer asynchronous versions of the resolution functions, like glibc offers getaddrinfo_a().
There are asynchronous resolution libraries, that wrap around the synchronous system resolver functions. At first libasyncns comes to my mind.
Boost.Asio supports to use the resolver with a thread pool. See here.
The most portable solution is indeed to use a separate thread for name resolution. This is also documented in MSDN.
Non portable solutions exist that perform asynchronous name looksups.
Linux glibc 2.2.3+: getaddrinfo_a
Windows: WSAAsyncGetHostByName IPv4 only :(
There are asynchronous DNS libraries out there: TADNS for example looks easy enough.
Related
I have a epoll server which sometimes opens outgoing connections, using their hostnames representation. Because of high rate of incoming connections flow, I don't want to block somewhere like getaddrinfo() or gethostbyname(). Sure, I could implement a cache plus a new thread, where the hostname resolution would be performed. Is there a single-threaded non-blocking way to resolve a hostname to an IP?
There are various libraries for the purpose, e.g. libevent contains a resolver.
I sort of agree with #Puciek though, doing this in a single thread adds quite a bit of complexity for questionable benefits. Using a dedicated resolving thread and communicating with it through pipes might be the best solution.
Since you mention epoll I guess you're using Linux. It has a getaddrinfo_a function that if I understand correctly does part of this for you. It clones a thread and runs getaddrinfo there. I never used it though so can't help beyond that.
I am a newbie programmer in linux domain. I am basically a MicroController programmer familiar with C. Now I am into little PC programing and need some inputs.
I am opening a socket and sending a Broadcast looking for my Embedded device on network. First I am probing the interfaces on the machine and will be broadcasting in each subnet, a call to my device with a signature. The device is listening on that particular port and it responds with its signature. The program then gets the ip and other details of my device and will start communicating.
I am sending a call in one function in each interface and to avoid blocking I am creating another listening thread to get response which may take some time to arrive. On receiving response I need to inform other thread about this and data to be given to them.
In this scenario, which is the best method to do that? Signal, Message or flag or whatever?
Since I need to implement this code in windows also, it will be good if it is possible to use a mechanism which is possible in both platforms.
Please suggest
Roy Thomas
It is a classic network programming issue. Personally, when I do network programming at this level in C++ , I use the C++ POCO libraries (see this).
You do not specify whether you use UDP or TCP. If you use TCP, the library provides something called TCPServer framework that deals with these issues, i.e. managing a pool of worker threads that deals with connections.
These slides, starting at slide "The TCPServer Framework", explain the principle.
Then you can use FIFO to communicate between your threads or POCO libraries notifications.
Have a look at Qt Creator its a cross platform C++ IDE it has very good implementation for signals and slots.
Its got its own library of functions that extend the STL and some very nice threading ones that you should take a look at.
I know this may not have been the answer you were looking for but i use Qt every day and its great! so feel free to ask any questions ...
I'm programming a network protocol over UDP, using C/C++ in Linux. The protocol must provide reliability, so I'm going to simulate something like TCP retransmission over UDP.
This can be done using pthreads or fork, but I believe that's an overkill and consumes a lot of system resources. A better approach is to exploit a scheduler.
I probably can't use Linux internal scheduler, since I'm programming in user space. Are there standard C/C++ libraries to accomplish this? How about 3rd party libraries?
Edit: Some people asked why I'm doing this. Why not use the TCP instead?
The answer is, since I'm implementing a tunneling protocol. If someone tunnels TCP over TCP, the efficiency will drop considerably. Here's more info Why TCP Over TCP Is A Bad Idea.
The "scheduler" you're after is called "select", and it's a user-space call available in linux. Type "man 2 select" to read the help page for how to use it.
If you need a timeout, just call select() with a timeout value. The select call will return either when new data has arrived, or a timeout has expired. You can then do retransmissions if there was a timeout.
Here's a sample of how to accomplish asynchronous coroutines with Boost. Boost manages the overhead of creating a thread to run the coroutine in this case so that you don't need to. If you would like the kernel to manage your interrupts, you can use alarm & setitimer, but they're very limited in what they can do.
Any solution will include threads, forks, or some variant of them at some level, unless you synchronously manage the transmission in the main thread using something like select().
Not clear what exactly you are trying to schedule. You can use libevent for efficient and somewhat portable interface. This is basically similar to Matthew's suggestion of using select, but using the most efficient interface (which select is not) on FreeBSD, Linux and MacOS X (actually their page now claims Windows support as well but I'm not too familiar with that).
This will give ability to do non-blocking event-driven network calls. It will not solve the scheduling part. DOing it in a separate thread is not going to hurt your performance. I think running a pthread per connection is not the best approach, but having a single scheduling thread and some worker threads dealing with the network events and maybe some non-trivial processing usually works well.
I am currently involved in the development of a software using distributed computing to detect different events.
The current approach is : a dozen of threads are running simultaneously on different (physical) computers. Each event is assigned a number ; and every thread broadcasts its detected events to the other and filters the relevant events from the incoming stream.
I feel very bad about that, because it looks awful, is hard to maintain and could lead to performance issues when the system will be upgraded.
So I am looking for a flexible and elegant way to handle this IPC, and I think Boost::Signals seems a good candidate ; but I never used it, and I would like to know whether it is possible to provide encapsulation for network communication.
Since I don't know any solution that will do that, other then Open MPI, if I had to do that, I would first use Google's Protocol Buffer as my message container. With it, I could just create an abstract base message with stuff like source, dest, type, id, etc. Then, I would use Boost ASIO to distribute those across the network, or over a Named PIPE/loopback for local messages. Maybe, in each physical computer, a dedicated process could be running just for distribution. Each thread registers with it which types of messages it is interested in, and what its named pipe is called. This process would know the IP of all the other services.
If you need IPC over the network then boost::signals won't help you, at least not entirely by itself.
You could try using Open MPI.
I'm working on an instant messenger client in C++ (Win32) and I'm experimenting with different asynchronous socket models. So far I've been using WSAAsyncSelect for receiving notifications via my main window. However, I've been experiencing some unexpected results with Winsock spawning additionally 5-6 threads (in addition to the initial thread created when calling WSAAsyncSelect) for one single socket.
I have plans to revamp the client to support additional protocols via DLL:s, and I'm afraid that my current solution won't be suitable based on my experiences with WSAAsyncSelect in addition to me being negative towards mixing network with UI code (in the message loop).
I'm looking for advice on what a suitable asynchronous socket model could be for a multi-protocol IM client which needs to be able to handle roughly 10-20+ connections (depending on amount of protocols and protocol design etc.), while not using an excessive amount of threads -- I am very interested in performance and keeping the resource usage down.
I've been looking on IO Completion Ports, but from what I've gathered, it seems overkill. I'd very much appreciate some input on what a suitable socket solution could be!
Thanks in advance! :-)
There are four basic ways to handle multiple concurrent sockets.
Multiplexing, that is using select() to poll the sockets.
AsyncSelect which is basically what you're doing with WSAAsyncSelect.
Worker Threads, creating a single thread for each connection.
IO Completion Ports, or IOCP. dp mentions them above, but basically they are an OS specific way to handle asynchronous I/O, which has very good performance, but it is a little more confusing.
Which you choose often depends on where you plan to go. If you plan to port the application to other platforms, you may want to choose #1 or #3, since select is not terribly different from other models used on other OS's, and most other OS's also have the concept of threads (though they may operate differently). IOCP is typically windows specific (although Linux now has some async I/O functions as well).
If your app is Windows only, then you basically want to choose the best model for what you're doing. This would likely be either #3 or #4. #4 is the most efficient, as it calls back into your application (similar, but with better peformance and fewer issues to WSAsyncSelect).
The big thing you have to deal with when using threads (either IOCP or WorkerThreads) is marshaling the data back to a thread that can update the UI, since you can't call UI functions on worker threads. Ultimately, this will involve some messaging back and forth in most cases.
If you were developing this in Managed code, i'd tell you to look at Jeffrey Richter's AysncEnumerator, but you've chose C++ which has it's pros and cons. Lots of people have written various network libraries for C++, maybe you should spend some time researching some of them.
consider to use the ASIO library you can find in boost (www.boost.org).
Just use synchronous models. Modern operating systems handle multiple threads quite well. Async IO is really needed in rare situations, mostly on servers.
In some ways IO Completion Ports (IOCP) are overkill but to be honest I find the model for asynchronous sockets easier to use than the alternatives (select, non-blocking sockets, Overlapped IO, etc.).
The IOCP API could be clearer but once you get past it it's actually easier to use I think. Back when, the biggest obstacle was platform support (it needed an NT based OS -- i.e., Windows 9x did not support IOCP). With that restriction long gone, I'd consider it.
If you do decide to use IOCP (which, IMHO, is the best option if you're writing for Windows) then I've got some free code available which takes away a lot of the work that you need to do.
Latest version of the code and links to the original articles are available from here.
And my views on how my framework compares to Boost::ASIO can be found here: http://www.lenholgate.com/blog/2008/09/how-does-the-socket-server-framework-compare-to-boostasio.html.