I'm looking into using the Boost::Beast websocket library to create an asynchronous bidirectional pipe to pass data between a server and a client. I leveraged some code from the async example (I can post some at a later time if necessary, don't have access to it now). I currently have a class which creates several threads running a SocketListener. When a client connects, it creates a Session shared_ptr to do the async read and write functions. The problem is, this session object will only write out when the client has sent me a message. I'm looking for an implementation that allows my server to write on demand to all the clients connected to it and also listen for incoming data from those connections.
Is this possible? Am I using the wrong technique for this? The other way I though this may be achievable is to have an incoming websocket and and outgoing websocket. Incoming would allow a client to drop configurations for the server and outgoing would just monitor a message queue and do a async write if a message is available.
Thanks!
Is this possible?
Yes
Am I using the wrong technique for this?
No
The other way I though this may be achievable is to have an incoming websocket and and outgoing websocket, and No respectively.
That is not necessary, a websocket stream is full-duplex. You can read and write at the same time.
outgoing would just monitor a message queue and do a async write if a message is available.
This is the correct approach, but you can do that in the same Session object that also handles the reads.
Here's an example that reads continuously and can also write full-duplex: https://github.com/vinniefalco/CppCon2018
Related
I'm currently trying to develop a server and some clients which communicate with each other using something like a proxy in the middle. The "proxy" will have sockets opened to every client and server on the system. This means that I'm currently using threads to keep all the connections opened. Every time a client decides to send a message it uses its socket with the proxy and sends the message. Then the proxy will propagate the message to every other node using the respective socket.
As you can see, a node can be receiving messages by having the proxy writing on the socket or a node may want to send messages by writing on the socket.
How do I guarantee that the content in the socket does not get overwritten ? Do I have to use mutexes to lock the access to the socket ? What is a good practice to solve this problem ?
Connections are bi-directional. Content going one way does not overwrite content going the other way. No mutex is needed for this.
Besides, you couldn't use a mutex anyway, as both sides of the connection are separate.
I am looking into possibility of listening on different sockets at once. To handle multiple socket connection at the same fd_set can be used in Linux. I have seen that gRPC also support this functionality with having epoll based pollset.
https://github.com/grpc/grpc/blob/18df25228cfa1f97fc5cca9176fbaef64c0e4221/doc/epoll-polling-engine.md
I intend to call different services in async mode and providing a service at the same time. Therefore, I was thinking about having a poll-set consist of client sockets waiting for async responses and server sockets. It seems to be possible in gRPC. I haven't been able to find anything in gRPC API that exposes construction of a poll-set.
Therefore, my question is how to use this capability of gRPC?
Does gRPC manages this automatically? In that case how can I wait for incoming messages?
The same CompletionQueue should be used for both client and server. To wait for the incoming messages next needs to be invokek.
I am working on a project currently where I have a web-server. I have to add the ability so that for each request, I need to send multiple requests to other servers, get responses, and send back results to the original client. These servers are high throughput, so I was getting worried about the number of sockets as well as the speeds of setting up new threads/sockets for sending out many requests over many sockets. So I started thinking that have a single(or a few connections), open to each client would help solve this problem. I wasn't sure how persistent connections and boost ASIO worked though. Some questions I had:
-How can I set keep alive times using ASIO tcp sockets.
-Can I send out multiple concurrent requests over the same socket? Would I run into an issue with the order of the results(Each result should have an Id, so I don't mean order as in results being sent out of order, but more packet order, if a response is more than one packet, will I have a problem with the order of the packets).
All requests are HTTP GET/POST requests if that matters too.
Any information in this subject would be appreciated. Thanks.
A TCP socket acts as a data stream, the data you write on one end will be received in the same order in the other end. You can send multiple requests over the same socket if your protocol can handle it.
You mention concurrent requests, therefore you need to be very careful to not interleave the write calls of two different requests. If you can ensure that each result is written atomically, then I see no problem in using a socket for multiple requests (you can do that with a reply queue).
You can set the standard socket keep alive here.
Hi to all the experts out there :)
This is my first question here.
Problem Description :
I have to write a Market Data Feed Handler. This is going to be a Windows Service, will be using two Sockets.
Socket A : For communication between Subscribing applications and Feed Handler (Feed Handler will be accepting the connection request and the Item Request).
Socket B : For communication between Feed Handler and External Market Data provider, like Reuters/Bloomberg.
In both the cases Request/Response will be using the same port.
Note : The volume of Data coming from the external system is low (External system will only send the information which has been subscribed for, at this point of time).
However later on we may want to scale it, some providers throw all the data, and Feed Handler has to filter out locally, based on the subscription.
My questions :
What threading model i should use?
Which I/O strategy i should use?
Keeping in mind both the cases, should i create separate Request/Response thread?
EDIT 1: After reading few tutorials on Winsock, i'm planning to use Event Objects for asynchronous behavior.
The point of concern here is that, a single thread should listen for incoming client connections (Accept them) and also Connect to other server, in turn send/recv on two different ports.
Thread A
1) Listening for incoming connections. (Continuous)
2) Receiving Subscribe/Unsubscribe request from connected clients. (Rarely)
3) Connect to the external server (Onetime only).
4) Forward the request coming from client to the external server. (Rarely)
5) Receive data from external server. (Continuous)
6) send this data back to the connected clients. (Continuous)
My question is can a single thread act as both Client and Server, using asynchronous I/O models?
Thanks in advance.
Deepak
The easiest threading model seems to be single threaded synchronous. If you need to implement a filter for a provider, implement that as a socket-in/socket-out separate process.
I currently have a basic chat program in c++ that uses WinSock2.h with UDP. Currently the user is able to send a message to the server and the server just sends the same message back. I was wondering where do I go from here (i'm not asking for code). I was wondering how I should go forward in having the messages get sent to another client that is also connected to the server.
If I need to explain what I have done already please let me know.
All suggestions are greatly appreciated.
Thanks
You would have a list of currently connected users, when a user sends a message, it would then post it to all connected users.
Your server would keep track of who is connected, and remove those who get disconnected. When someone connect or disconnects, it would send a notification to all currently connected users, telling them of this notification.
All this is not specific to UDP, infact, TCP would probably be better for this type of messaging as you do not have to worry about messages being dropped. UDP should only be used where performance is of upmost importance, like real-time gaming, voice chat.
When you're saying "connected" (in the context of clients) - what exactly do you mean?? Because you say you're using UDP in your program.
In the UDP protocol there's no "connected" state, unless you implement it.
In the TCP protocol however, there is (implemented within the protocol itself).
Furthermore, the basic idea of "broadcasting" a message is simple - keep a list of connected clients.
Add a client when it connects. Remove it from the list when it disconnects.
Then when you want to send a message to everyone you just iterate through this list.
Again, you'll have to receive those dis/connect events before you could keep track of "connected" clients.
If you go with TCP instead of UDP then you're set.
Good luck.
Basically, like Matthew said, you need to store all the current connections to the server. When a socket connects you can store a reference to that socket. Now whenever a client sends a message you can rebroadcast that to all the sockets. Now you have to handle when sockets disconnect as well since you don't want to store a bunch of closed sockets.