I'm working on a project where I have a single client that need to open a Telnet session to multiple servers (100) and wait for messages. The messages are small (< 80 bytes) and will occur at random.
I've read that it's bad form to do this by creating a thread for each "server". I'm looking for suggestions as to the best way to handle the multiple sites with TCPClient, or Winsock or Catalyst or ???
Thanks for the help !
Gary M
As it is Windows platform, there are many options. You can use Winsock select function, or WSAPoll, or WSAAsyncSelect, or completition ports.
select/WSAPoll work almost like in Posix, and there are plenty of examples, and some ready libraries on how to use those.
WSAAsyncSelect will send events to the UI thread (you need to have window for that). If you application has a window, this might be the simplest option, as all activity will occur in the window thread, and library takes care of event serialization.
Also take a look at (it is important as you have more then 64 connections):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms739169(v=vs.85).aspx
Using Windows completition ports:
http://msdn.microsoft.com/en-us/magazine/cc302334.aspx
http://msdn.microsoft.com/en-us/magazine/ms810436.aspx
Related
I want to create a chat program between a server and a client, I want the client or server to be able to send message to the other end at anytime without waiting for example:
Client: hi
Server: hi
Server: I'm the server.
Server: How are you?
Client: Good.
In this example the Server doesn't wait for the Client to reply and sends another message at anytime.
Should I use the function select?, If so how should I determine the timeout and is the timeout value is the solution for busy waiting?
Is select function is the best approach for this problem?
Thanks.
Using select seems like the right approach, especially if you want the program to work on Windows. This will allow you to block the process and wait for a message from multiple clients simultaneously.
In general you should set the timeout to NULL so that the server will block indefinitely for a request from a client. The timeout is only useful if you want to additionally wake up the server at regular intervals for other reasons.
If you are targetting Unices (like Linux) it is easier and more efficient to use poll. This does basically the same thing but the interface is easier to work with. select becomes quite awkward to use if the file descriptor numbers become larger than 1024, which is a problem if you ever expect your server to handle large numbers of clients.
If you are targeting Linux specifically and don't care about portability you can even use epoll which has even more performance advantages and is arguably easier to use.
If you are only targeting Windows, you can create event objects for each of the sockets and then use WaitForMultipleObjectsEx to wait for data from any of them. This provides similar functionality to poll but the API is quite involved.
Is there a conventional way to write a program such that commands can be issued to the program from the command line without a repl? For example, how you can send commands to a running nginx server using sudo /etc/init.d/nginx restart (or any other valid command besides restart)
One idea I had was having the long-running program create and monitor a unix socket that other programs can write to to send it commands. Another was to create a local server with a REST interface that can be sent commands that way, though that seems a bit gross.
What's the right way to do this?
Both ways are ok, and you could even consider using some RPC machinery, such as making your application serve JSONRPC on some unix(7) socket. Or use a fifo(7). Or use D-Bus.
A common habit on Unix is to have applications reload their configuration files on e.g. SIGHUP signal, and save some persistent state (before terminating) on SIGTERM. Read signal(7) (notice that only async-signal-safe routines can be called fro signal handlers; a good way is to only set some volatile sig_atomic_t variable inside the handler and test it outside). See also POSIX signal.h documentation.
You might make your application become a specialized HTTP server (e.g. using some HTTP server library like libonion) and give it some Web interface (or REST, or SOAP ...); the user (or sysadmin) will then use his browser to interact with your application.
You could make your server systemd compatible. (I don't know exactly what that requires, it is perhaps D-bus related).
You could embed some command interpreter (like Guile and Lua) in your app and have some limited kind of REPL loop running on some IPC like a socket or a fifo. Beware of nasty code injection.
I had a similar issue where I have a plethora of services running on any number of machines and each is in need of communicating with several others.
My main problem was not so much the communication between the services. That can be done with a simple message sent over a connection (as Basile mentioned, it can be TCP, UDP, Unix sockets, FIFOs...). However, when you have over 20 services, many of which need to communicate with several other services, you start having a headache on how to get all the connections right (I have such a system, although it has a relatively limited number of services, like just 10 and that's already very complicated).
So I created a process (yet another service) called Communicator. All services connect to the Communicator service and when they need to send a message, they include the name of the service they want to reach. The Communicator service is in charge of sending the message to the right place—i.e. it could be to another Communicator service running on a different computer. Communicator has a graph of all the services available on your network and knows how to send messages to them without your service having to know anything about all of that. Computing a graph can be really complex.
For the purpose, I created the eventdispatcher project. It is in C++, which may not be what you're interested in, although you could use it in other languages that interface with C/C++. The structure of the messages are "proprietary" (specific to the Communicator), but you can create any message you want. A message includes a name and parameters (param-name=value). The first version has a simple one line text communication system. The newer version accepts JSON as well (still must be one line of text per message).
The system supports TCP, UDP, Unix sockets, FIFO, and between threads, you can have thread safe fifos. It also understand signals (like SIGHUP, SIGTERM, etc.) It has a specific connection to listen for the death of a thread. It supports encryption over TCP via OpenSSL. The messages can automatically be dispatched (hence the current name of the library). Connections are assigned a timer. And there are CUI and GUI (Qt) extensions as well.
The one main point here is that all your connections can be polled (see poll()) and thus you can implement a system that reacts to events instead of a system which sleeps and checks for events, sleeps and check, etc. or worth, you have a single blocking connection and everything has to happen on that one connection or your service gets stuck. This is one reason Unix has been using signals since early version of Unix did not have select() nor poll().
I'm making a IRC client using LUA. I'm using the the libraries that came with "Lua for Windows ". So I'm using luasocket for the comms and IUP for the UI bits.
The problem I'm having is that I'm getting stuck in a loop when I read the IO. I tried the timer in IUP but that didn't seem to work.
I'm was looking for a way to delay the IO read loop.
I set the time out for the reads to 0 and that worked.
You are probably making a blocking read on a TCP socket inside the GUI thread. That will lock up your whole application if you do not receive the expected data in a timely manner. Either perform the socket I/O in a separate thread (see Lua Lanes) or use non-blocking I/O (see settimeout).
The Kepler Project is a great resource for guidance on networking applications with Lua, but it is focused on web applications versus an IRC client. For example, the Copas library uses Lua coroutines to handle multiple TCP connections.
Now if you really just wanted to know how to create a delay in Lua, then the Sleep Function article in the lua-users wiki should provide all the information you need.
Nginx uses epoll, or other multiplexing techniques(select) for its handling multiple clients, i.e it does not spawn a new thread for every request unlike apache.
I tried to replicate the same in my own test program using select. I could accept connections from multiple client by creating a non-blocking socket and using select to decide which client to serve. My program would simply echo their data back to them .It works fine for small data transfers (some bytes per client)
The problem occurs when I need to send a large file over a connection to the client. Since i have only one thread to serve all client till the time I am finished reading the file and writing it over to the socket i cannot resume serving other client.
Is there a known solution to this problem, or is it best to create a thread for every such request ?
When using select you should not send the whole file at once. If you e.g. are using sendfile to do this it will block until the whole file has been sent. Instead use a small buffer, and send a little data at a time to each client. Then use select to identify when the socket is again ready to be written to and send some more until all data has been sent. This will allow you to handle multiple clients in parallel.
The simplest approach is to create a thread per request, but it's certainly not the most scalable approach. I think at this time basically all high-performance web servers use various asynchronous approaches built on things like epoll (Linux), kqueue (BSD), or IOCP (Windows).
Since you don't provide any information about your performance requirements, and since all the non-threaded approaches require restructuring your application to use these often-complex asynchronous techniques (as described in the C10K article and others found from there), for now your best bet is just to use the threaded approach.
Please update your question with concrete requirements for performance and other relevant data if you need more.
For background this may be useful reading http://www.kegel.com/c10k.html
I think you are using your callback to handle a single connection. This is not how it was designed. Your callback has to handle the whatever-thousand of connections you are planning to serve, i.e from the number of file descriptor you get as parameter, you have to know (by reading the global variables) what to do with that client, either read() or send() or ... whatever
Is there any benefit on Windows to use the WSA winsock functions compared to the BSD-style ones?
The most significant difference is the availability of Asynchronous Event style APIs in Winsock.
With Berkeley sockets, each time you read or write your application will "block" until the network is ready, which could make your application unresponsive (unless the network I/O is handled in a different thread).
With an async interface, you can arrange for a callback function to be called as part of the normal windows message loop each time data is received or when the transmit buffer is empty.
Only if you plan to deploy to a legacy platform like Windows 95 or there is something in the winsock API that you absolutely cannot live without and you don't want to roll yourself (<-- doubtful tho).
If you design around the BSD paradigm, your code can work on other platforms with less porting work. If you assume that your network library will support asynchronous I/O (as Alnitak mentions), you're going to have to do a lot more work if that gets pulled out from under you.
Of course, if you're sure you'll never leave the warm bosom of Microsoft, feel free to go to town.
With respect to Alnitak's answer, I agree - I'd just add that you need not use a message loop to use asynch operations on sockets. Using I/O completion ports is a very scalable way to build a high-performance networked application.