I have to design a server socket program.The requirement is Each connection from client will be in different threads.
The challenge is Suppose Server is now connected with two client Client A and client B.They will be in two different thread.
My application requirement is when server will get some message from Client A or Client B ,after processing this message it will send the messages to both Client A and client B.
Can you please suggest what will be the right approach for it .How to know what clients are open at a time .
Quite simple really - have data structures shared by the two threads and protected from concurrent access. You can design the sending based on a message queue like pattern.
Related
Intro:
In the below architecture, there are three key components.
Users - Machines where user application is running.
Applications - which are running inside the remote server.
Gateway/Broker - Required for isolation between user devices and server applications.
Message flow between user device and server application should happen as below
User shall transmit message to remote server, which will be used by
the one or more server applications.
Application shall broadcast/publish message to all connected
users.
Application shall send message to a particular user device
(Unicast).
In addition, one or more users will be connected or disconnected to the server arbitrarily and one or more application will be spawned or terminated arbitrarily.
For the above problem statement, I have designed the below zmq architecture.
The Gateway/Broker handles arbitrary assignments of users and applications and also provides the required isolation. It publishes user messages to all applications. It also aggregates all messages needed to be sent to users from applications via a SUB socket.
The application sends a two part message, the first part is the user identity and the second part is the actual message. The Gateway/Broker transmits that message to a user, based on identity. A special identity for a broadcast will be created, the gateway, if has received broadcast identity, will publish the message to all users via PUB socket.
The user connects to both ROUTER and PUB sockets in gateway. Fair queued data will be received from both sockets. While sending, the message will be sent to only gateway's ROUTER socket, not PUB socket.
Questions:
Q1: Is there any flaw with above architecture?
Q2: Is it possible to improve it more?
Metric assumed for the Q2:
The users and applications are dynamic in nature, they connect and disconnect on their own, the design should withstand that,
User reports its status periodically to server, design should facilitate latency of less than 333 [ms] ( a user, connected to server over internet, WAN connectivity btw user and server provides a latency much less than 333 [ms] )
Lossless transmission between server and users ( ACKing at backend, retransmission if lost )
You can try Malamute, which gives you what you need and more like credit-flow, keep-alive, tracking.
Malamute is small broker based on zeromq and part of the zeromq community. You can run Malamute as a component inside your application and don't need a dedicate service or daemon for it.
If you are using C or C++ that is no brainer as it integrate naturally. It also has binding for a lot more languages.
https://github.com/zeromq/malamute
I am implementing a hub/servers MPI application. Each of the servers can get tied up waiting for some data, then they do an MPI Send to the hub. It is relatively simple for me to have the hub waiting around doing a Recv from ANY_SOURCE. The hub can get busy working with the data. What I'm worried about is skipping data from one of the servers. How likely is this scenario:
server 1 and 2 do Send's
hub does Recv and ends up getting data from server 1
while hub busy, server 1 gets more data, does another Send
when hub does its next Recv, it gets the more recent server 1 data rather than the older server2
I don't need a guarantee that the order the Send's occur is the order the ANY_SOURCE processes them (though it would be nice), but if I new in practice it will be close to the order they are sent, I may go with the above. However if it is likely I could skip over data from one of the servers, I need to implement something more complicated. Which I think would be this pattern:
servers each do Send's
hub does an Irecv for each server
hub does a Waitany on all server requests
upon completion of one server request, hub does a Test on all the others
of all the Irecv's that have completed, hub selects the oldest server data (there is timing tag in the server data)
hub communicates with the server it just chose, has it start a new Send, hub a new Irecv
This requires more complex code, and my first effort crashed inside the Waitany call in a way that I'm finding difficult to debug. I am using the Python bindings mpi4py - so I have less control over buffers being used.
It is guaranteed by the MPI standard that the messages are received in the order they are sent (non-overtaking messages). See also this answer to a similar question.
However, there is no guarantee of fairness when receiving from ANY_SOURCE and when there are distinct senders. So yes, it is the responsibility of the programmers to design their own fairness system if the application requires it.
I have a very simple netty app which serves both as server and a client.
Client uses channel.writeAndFlush() to send request to server and then blocks on monitor.wait().
In client's InboundAdapter in channelRead() I find the appropriate monitor and do monitor.notify() to let the requesting client thread to proceed working on the server's reply.
On the server in ChannelHandler's channelRead() I do the following:
To limit the amount of requests being processed I submit a task which does the real work as a new task to existing EventLoop: ctx.executor().submit(new Task()). I that task I do heavy IO operations and after that I writeAndFlush() results back to client.
Here is my pipeline setup:
new ObjectEncoder(),
new ObjectDecoder(LibConstants.Search.MAX_REQUIEST_SIZE, ClassResolvers.cacheDisabled(null))
Here is the bootstrap config:
new ServerBootstrap()
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 1000)
.option(ChannelOption.SO_KEEPALIVE, true)
I have 2 problems:
Rather often I get io.netty.handler.codec.DecoderException: java.io.UTFDataFormatException on the client when receiving a reply from server. I cannot find any obvious reason for this. Since my pipeline setup is so simple.
A reply from the server just wouldn't appear on the client. I the logs I see a successful flush on the server but the reply never arrived at the client. This is very hard to deal with since my app is very latency sensitive. Any timeout I would set will kill my user experience.
This all happens over a VPN network so there is a possibility that VPN device misbehaves in some weird way but I hoping that TCP would handle any sort of packet loss/corruption which can happen in the channel.
Any advice or experience you can share will be very appreciated!
I am trying to create a Web Server of my own and there are several questions about working of Web servers we are using today. Questions are:
After receiving a HTTP request from a client through port 80, does server respond using same port 80?
If yes then while sending a large file say a pic in MB's, webserver will be unable to receive requests from other clients?
Is a computer port duplex or simplex? (Can it send and receive at the same time)?
If another port on server side is used to send response to client, then (if TCP is used, which is generally used), again 3-way handshaking will be done which will be overhead...
http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html here is a good guide on what's going on with webservers, although it's in c but the concepts are all there. This will explain the whole client server relationship as well as some implementation details.
I'll just give a high level on what's going on:
Usually what happens is when your server gets a new request that comes in it creates a fork that will process it, that way you are not bogged down by each request, when the request comes in the child process is handed a new file to write to(again this is all implementation details).
So really you have one server waiting for requests and for each request it received it spawns a child to process to deal with this request. I'm sure there are much easier languages to implement this stuff than c(I had to do both a c and java server serving to either one in my past) but c really gets you to understand the things that are going on and I'm betting that is what you are looking for here
Now there are a couple of things to think about:
how you want the webserver to work. The example explains the parent child process.
Do you want to use tcp/UDP there are differences in the way to payload gets delivered.
You don't have to connect on port 80. that's just the default for web.
Hopefully the guide will help you.
Yes. The server sends the response using the TCP connection established by the client, so it also responds using the same port. The server can handle connections from multiple clients using the same port because TCP connections are identified by (local-ip, local-port, remote-ip, remote-port), so the server can even handle multiple connections from same client provided that the source ports are different.
There are different techniques you can use to be able to serve multiple clients at the same time. These include
using multiple processes or threads: when one is busy serving a client the others can serve other clients.
using events: the server listens for events from the OS: when it can write a block of data to a connection it writes it, when a new client connects it accepts the connection, ...
Frequently both approaches are be combined.
A TCP connection is duplex: you can send and receive at the same time. The HTTP protocol is based on a simple request-response model though: at any given time only one party is "talking."
I need to create an application that:
Has one server
With a client that connects to the server and sends 8 longs (data from 8 sensors: rain, air humidity, wind speed...) 1 sensor data / long (sensor data is acquired from a custom USB device)
User clients. The end user runs this type of client to connect to the server for data retrieval from the sensors.
I used Qt before, creating Client-server applications with just one type of client. And I managed to create this application too, just at a smaller scale (used 5 words, and clients were connected simultaneously to the server). I used the Qt network examples fortune threaded server and http://goo.gl/srypT and blocking fortune client example.
How can i identify which client is which? (since they have different ip everytime they connect to internet). On my small scale application, I created some kind of protocol, but there must be a more efficient way to do this.
I assume that you want to identify the client type ("sensor client" vs. "user client"), not individual client instances.
The straightforward way to do this is to implement a protocol, as mentioned in the question. For your use case, this could be very simple:
let the "sensor client" send a "write" command (one character like "w" would be sufficient) followed by your sensor data. The server then receives the "w" command and knows that he needs to read sensor data from the client.
let the "user client" send a "read" command (e.g. the character "r"). When the server receives the "r" command it knows that it needs to send data to the client.
If, for whatever reason, you do not want to implement even such a simple protocol, you could also set up two separate QTcpServer instances which listen at different ports, lets say 8192 and 8193. Your "sensor client" would then connect to port 8192, and the server knows by the port number that the client will send data. Your "user clients" would connect to port 8193, and the server knows that the clients expect data and will send the required data.
In any case, you should be aware that there is no authentication and authorization involved, and any client who knows the simple protocol and/or the port numbers can send and receive data.
To identify a client, you have to use some kind of client ID. Usually, some kind of hash (a MD5 digest, a UUID or a GUID) is used as the client ID. This client ID have to be sent from the client to the server when the client connects to the server.
What happens after the client has been identified and accepted, depends on the type of connection (protocol). If you use a stateful protocol, the same connection will be kept open as long as the client uses it so there is no need to re-identify the client. If you use a stateless connection (HTTP, for example), you will have to re-send the same ID from the client to the server every time the client requires data (that is: a document, a page, etc.) to the server.
A simpler and more efficent way to deal with a client/server architecture like this consists in using an existing, proven server of some kind. For example, you could use a RESTful web server like Wt (http://www.webtoolkit.eu/wt/blog), given that you are already using C++.
Even better, I would use a Ruby- or a Python-based RESTful web service framework like:
http://www.sinatrarb.com/
http://bottlepy.org/docs/dev/
http://flask.pocoo.org/
Or the new Ruby-on-Rails API:
http://blog.steveklabnik.com/posts/2012-11-22-introducing-the-rails-api-project
https://github.com/rails-api/rails-api
Developing the server in Ruby or Python is much faster and easier. The client can developed in any way (C++ with Qt, Javascript in a web browser and many other ways)