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.
Related
I'm writing an application where a client will connect to a server and subscribe to data updates. The client tells the server what data items it is interested in, and then subscribes using a method with a streaming response. This works well.
However, there are also non-data related notifications that the client should know about. I'm not sure about the best way to handle those. I've thought of:
Adding another method to the existing service. This would be just like the data subscription but be used for event subscription. The client could then subscribe to both types of updates. Not sure what the best practice is for the number of methods in a service, or the mixing of responsibilities in a service.
Exposing a second service from the server with a streaming method for event notifications. This would make the client use multiple connections to get its data - and use another TCP port. The event notifications would be rare (maybe just a few during the lifetime of the connection) so not sure if that is important to consider. Again - not sure about best practices for the number of services exposed from a server.
This one seems unorthodox, but another method might be to pass connection info (IP address and port) from the client to the server during the client's connection sequence. The server could then use that to connect to the client as a way to send event notifications. So the client and server would each have to implement both client and server roles.
Any advice on ways to manage this? Seems like this a problem that would already have been solved - but it also appears that the C++ implementation of gRPC lags a bit behind some of the other languages which offer some more options.
Oh - and I'm doing this on Windows.
Thanks
I've come up with another alternative that seems to fit the ProtoBuf style better than the others. I've created ProtoBuf message types for each of the data/event/etc notifications that the server should send, and enclosed each of them inside a common 'notification' message that uses the 'oneof' type. This provides a way to have a single streaming method response that can accommodate any type of notification. It looks like this:
message NotificationData
{
oneof oneof_notification_type
{
DataUpdate item_data_update = 1;
EventUpdate event_data_update = 2;
WriteResponse write_response_update = 3;
}
}
service Items
{
...
rpc Subscribe (SubscribeRequest) returns (stream NotificationData) {}
...
}
Any comments or concerns about this usage?
Thanks
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
I have a few question about socket in c++!
First question, let's say that he writes a server for the game in which he will play 200 people at once, but accept is blocked because he already serves one client, how to deal with it?
Second question, how to download a list of all currently connected clients, so that you can then send a message to everyone?
I have a few question about socket in c++!
For future reference, please post only one question at a time. If you have multiple questions, post them separately.
let's say that he writes a server for the game in which he will play 200 people at once, but accept is blocked because he already serves one client, how to deal with it?
Use sockets in non-blocking mode, using select()/(e)poll() or other callback mechanisms to know which sockets have pending activity and when.
Otherwise, use accept() in a separate thread than other thread(s) used to service connected clients.
how to download a list of all currently connected clients, so that you can then send a message to everyone?
The server is responsible for keeping track of its connected clients. Then it can loop through that list when needed.
If a client wants to send a message to every other client, the best option is for it to send a single message to the server and ask the server to relay the message to every other client.
Otherwise, the client would have to request the list from the server, and then send a message to every other client individually.
Context (C++): I need to develop a network server, which can handle more than 1000 clients per second, with more than 100 requests per second.
Each request starts a state machine between the client and server, wherein the client and server exchange further data, before the server sends a final response.
Problem : Some of the processing is done by a third party library that requests callbacks from us and calls these callbacks when it requires some data from the client. So, we dont controll this thread and must wait for the data from client before we can process further.
Question: With such a high amount of messages, we decided we would use libevent or some of its derivatives e.g. https://github.com/facebook/wangle or https://github.com/Qihoo360/evpp.
The problem is that libevent is based on reactor pattern and we do not have a way to leave processing in a thread as soon as it enters the state machine.
So, my question is if the proactor pattern would be better here, and is there any library that can give us this behavior?
[Edit1]
OK, so after much deliberation, we decided that we should go ahead and make a "proxy" in front of our application. this proxy can then distribute the load to multiple running instances of our application using this 3rd party. Then we can use reactor pattern.
Any other suggestions are welcome..
The idea i'm having is that clients can connect to a chat room on a server and communicate with each other. In the chat room you should also be able to target another user and they should be able to talk with each other.
Now to the problem. I'm not sure which way is the easiest/best way to implement this. For the chat room I thought of when a user writes something, the message is sent to the server and the server then echoes that message to the other clients. Not sure what other options I have.
What i'm most confused about is how I can make only 2 clients talk to each other. Either the server act as a proxy and just forward the messages to the other client, this seem inefficient though. The only alternative to this I can think of is that the 2 clients establish a connection between each other. Which implementation is most common in order to achieve this?
I am using unix sockets with C++.
There are a few options for many-to-many chat and one-to-one chat. However, the only reasonably sane option for many-to-many chat is to do as you've said: send a message to the centralized server, the server relays the message to all other connected clients (or, in the same "room" / "channel").
For one-to-one chat, I recommend that you follow the same exact model: it's just a special case of the many-many chat relay in which the message is sent by the server, as a proxy, to only one other connected client. This is simple, and it hides every client's IP address from every other.
However, if the one-to-one communication were to become more voluminous than chat (e.g., a file transfer), direct one-to-one communication may be appropriate. In this case, the server should relay the initiation of a direct, peer-to-peer communication channel to the remote user, probably exchanging IP addresses upon setup, and the clients would then connect directly to each other for their special-purpose direct communication (while usually, though optionally, remaining connected to the server).
Thus, one-to-one communication is normally proxied by the server as in the general case of many-to-many, and the degree to which that practice is inefficient is superficial. Special purpose one-to-one communication (file transfers, VoIP, etc.) are done with direct client-to-client connections usually orchestrated at first by the server (i.e., to prepare each side for direct communication).
Implementation hint: the server is all TCP. Read about non-blocking sockets, the POSIX system call poll, and let the idea of message framing over TCP roll around in your head. You can then skip multithreading [and scalability] issues in the server code. The clients, besides speaking the same custom TCP protocol as your server, are up to you.
Well you can implement a multi-threaded client/server. A single "server" relaying the messages is the right way to go(to preserve global ordering of messages). Also think about leader election algorithms(http://en.wikipedia.org/wiki/Bully_algorithm) for example in case your "server" goes down. Check out
Another way to do this would be to use signals and event-driven programming.