Linux socket programming testing - c++

I am new to socket programming and I have written a code for the server using the epoll. Basically it would wait to accept for any client connection and it would send data to the clients if the data is available from other sources.
I need to test on how is the performance of the server when there are multiple requests for the connection and when the server is sending data to multiple clients. The question I have is how could I simulate a concurrent requests of the connection from a number of clients for the server? Do I create multiple threads to request or multiple processes or some other ways to test it?
Thanks.

I usually create a client program simulating one session with the server, find as many linux boxes nearby and spin up a thousand of them on each machine from a command line like:
for i in {0..1000} ; ./myprogram serverip & done
In some cases the protocol is text based and the interaction or test is simple, so I don't have to write myprogram but just use netcat, as in running nc serverip < input >/dev/null
If all you need is to test streaming data to your client, I'd start with netcat and work my way from there.
This approach is ok for my needs, I usually don't need to test more concurrency than a handful of thousand clients. If you need more scalability, you'll likely have to write the client simulator using io multiplexing (epoll) as well, having each instance simulate as much interactions as you can - and you'll have to do more controlled tests to find limits of your client .
Don't mix performance testing with functional testing though. While you might get awsome performance in a test environment, a live environment can be very different. e.g. clients will misbehave, they will disconnect at the most inapproriate of times. They might send you malicious data. They might be slow, leading to buildup of internal queues on the server or leving you with thousands of seemingly idle connections (killall -STOP nc while in the middle of sending data to test clients might show you interresting things)

You can do it using two threads one to send request and other to receive response.
To simulate multiple clients you can create multiple sub-interface using ifconfig command in a script or using ioctl in your c program.
For sending data from client you can create array of multiple sockets and bind them to different sub interface IPs and loop through them for sending data and use select or poll for receiving data from server.

Related

How to create multiple TCP connections within 1 gRPC stream

I'm using gRPC stream to transfer data from server to client, and am suffering low throughput. One thing specific to my case is: my client only sends control messages(eg, start, pause, resume), and server streams messages back till the end.
One thing I think could be useful is parallelization, and make full utilization of the b/w.
But one consideration is: my messages sent is ordered, which means if I open multiple multiple gRPC streams, I don't have a way to tell their order.
My question is: is there a way in gRPC to open multiple TCP connections?

ZMQ server/client pattern

It is a general question about patterns used in zmq. I'm trying to achieve the following.
Client can connect to one server
Multiple clients connect to the same server
Server receives connections from multiple clients
Server processes multiple messages in parallel
Think of any webserver, just without all the HTTP stuff around it. The question is the Paranoid Pirate Pattern a good candidate for such client/server? I guess it is a good idea to connect the backed socket to the workers using inproc since the queue and workers will be part of the same process, right? In case there is dozens to hundreds workers used, how should I work with the zmq::context_t? should I initiate it with high number of io_threads or use a zmq::context_t per worker?
EDIT001: Interestingly, zmq example of Paranoid Pattern does not work out of the box.

Are multiple boost::asio tcp channels faster than a single one?

In linux, axel is generally faster than wget. The reason is that axel opens multiple channels (connections) to the source and downloads the pieces of a file simultaneously.
So, the short version of my question is: Would doing the same with boost::asio make the connection transfer data faster?
By looking at these simple examples of a client and a server, I could make a single connection initiate multiple client instances, and connect to the same server with multiple sessions. In the communication protocol, I can make the client and server ready for such connections in such a way, where data is split among all the connection channels.
Could someone please explain to me why this should or shouldn't work out based on the scenarios I drew?
Please ask for more details if you need it.

What's the best RPC package to write a C++ client/server for a peer-to-peer system?

I have a program that performs compute-heavy local processing. The compute packages have 16MiB input buffers and generate between 10KB and 16MiB of output. This all happens in a multi-threaded environment.
I have a number of users who are compute-bound. I'm interested in adding support for peer-to-peer multiprocessing. That is, clients would be run on multiple computers in the organization. The master would find available clients, send them 16MiB buffers, and then get the results.
The master will have a list of available clients. It will then send a message to each client that it is free. The clients will start a thread for each core that they have. Each thread will ask the master for a work buffer, will compute the results, and will then send the results to the master. The master will incorporate the results from each client into the final output.
A typical run involves crunching between 100 and 50,000 16MiB buffers. The output is typically in the 100MB to 10GB range. There are no data dependencies between the buffers.
I'm looking for the best way to arrange the communications between the client and the server. My plan is to use some kind of RPC. I do not want to embed a web server in either the client or the server. Instead, my plan is to simply receive connections on a TCP socket and have some kind of basic RPC.
Here are the options I'm considering:
I can role my own client/server system and use protocol buffers to put the whole thing together.
I could use one of the existing RPC systems for potocol buffers.
I could embed a web server and use XMLRPC.
The implementation language is C++. The program compiles for Linux, MacOS, and with mingw for Windows.
Thanks.
We found that 0MQ met our criteria.

TCP/IP and designing networking application

i'm reading about way to implemnt client-server in the most efficient manner, and i bumped into that link :
http://msdn.microsoft.com/en-us/library/ms740550(VS.85).aspx
saying :
"Concurrent connections should not exceed two, except in special purpose applications. Exceeding two concurrent connections results in wasted resources. A good rule is to have up to four short lived connections, or two persistent connections per destination "
i can't quite get what they mean by 2... and what do they mean by persistent?
let's say i have a server who listens to many clients , whom suppose to do some work with the server, how can i keep just 2 connections open ?
what's the best way to implement it anyway ? i read a little about completion port , but couldn't find a good examples of code, or at least a decent explanation.
thanks
Did you read the last sentence:
A good rule is to have up to four
short lived connections, or two
persistent connections per
destination.
Hard to say from the article, but by destination I think they mean client. This isn't a very good article.
A persistent connection is where a client connects to the server and then performs all its actions without ever dropping the connection. Even if the client has periods of time when it does not need the server, it maintains its connection to the server ready for when it might need it again.
A short lived connection would be one where the client connects, performs its action and then disconnects. If it needs more help from the server it would re-connect to the server and perform another single action.
As the server implementing the listening end of the connection, you can set options in the listening TCP/IP socket to limit the number of connections that will be held at the socket level and decide how many of those connections you wish to accept - this would allow you to accept 2 persistent connections or 4 short lived connections as required.
What they mean by, "persistent," is a connection that is opened, and then held open. It's pretty common problem to determine whether it's more expensive to tie up resources with an "always on" connection, or suffer the overhead of opening and closing a connection every time you need it.
It may be worth taking a step back, though.
If you have a server that has to listen for requests from a bunch of clients, you may have a perfect use case for a message-based architecture. If you use tightly-coupled connections like those made with TCP/IP, your clients and servers are going to have to know a lot about each other, and you're going to have to write a lot of low-level connection code.
Under a message-based architecture, your clients could place messages on a queue. The server could then monitor that queue. It could take messages off the queue, perform work, and place the responses back on the queue, where the clients could pick them up.
With such a design, the clients and servers wouldn't have to know anything about each other. As long as they could place properly-formed messages on the queue, and connect to the queue, they could be implemented in totally different languages, and run on different OS's.
Messaging-oriented-middleware like Apache ActiveMQ and Weblogic offer API's you could use from C++ to manage and use queues, and other messaging objects. ActiveMQ is open source, and Weblogic is sold by Oracle (who bought BEA). There are many other great messaging servers out there, so use these as examples, to get you started, if messaging sounds like it's worth exploring.
I think key words are "per destination". Single tcp connection tries to accelerate up to available bandwidth. So if you allow more connections to same destination, they have to share same bandwidth.
This means that each transfer will be slower than it could be and server has to allocate more resources for longer time - data structures for each connection.
Because establishing tcp connection is "time consuming", it makes sense to allow establish second connection in time when you are serving first one, so they are overlapping each other. for short connections setup time could be same as for serving the connection itself (see poor performance example), so more connections are needed for filling all bandwidth effectively.
(sorry I cannot post hyperlinks yet)
here msdn.microsoft.com/en-us/library/ms738559%28VS.85%29.aspx you can see, what is poor performance.
here msdn.microsoft.com/en-us/magazine/cc300760.aspx is some example of threaded server what performs reasonably well.
you can limit number of open connections by limiting number of accept() calls. you can limit number of connections from same source just by canceling connection when you find out, that you allready have more then two connections from this location (just count them).
For example SMTP works in similar way. When there are too many connections, it returns 4xx code and closes your connection.
Also see this question:
What is the best epoll/kqueue/select equvalient on Windows?