Lets take an example. A client has 10 credits, it sends 3 read request by charging 5 credits each. How will the server reply to these requests?
It depends the network and the server speed.
If the server issued the first request before the third request comes then it will be fine, but if not the server will send an RST. (The server will close the connection)
The server has an inner credit counter, and if it lower than 0 the server assume that the client credit calculation is wrong , so the server close the connection, the client will reconnect to the server and the calcultion will start fresh.
Related
I am learning about: Client/Server Architecture (more concretely the characteristics). I have a question:
"Asymmetrical protocols: there is a many-to-one relationship between
clients and a server. Clients always initiate a dialog by requesting a
service. Servers wait passively for requests from clients." (Source:
https://docs.oracle.com/cd/E13203_01/tuxedo/tux80/atmi/intbas3.htm)
QUESTION: I do not understand, I see that like SYMMETRICAL.
For example: A client request a service (web page) to a server (web server), but before this request the server was waiting passively until it received a request from client, just in that moment there is a connection between client and server, the server says "here you have the web page which you requested". For that moment I think it is SYMMETRICAL.
So, why is it asymmetrical?
There is a many to one relation between clients and server, so there is a single server and many clients but a single server per client.
The client actively sends requests, while the server serves the request and does not initiate requests on its own.
The client is active and the server is passive, so it is assymetrical.
I'm new to ZeroMQ and trying to figure out a design issue. My scenario is that I have one or more clients sending requests to a single server. The server will process the requests, do some stuff, and send a reply to the client. There are two conditions:
The replies must go to the clients that sent the request.
If the client disconnects, the server should queue messages for a period of time so that if the client reconnects, it can receive the messages it missed.
I am having a difficult time figuring out the simplest way to implement this.
Things I've tried:
PUB/SUB - I could tag replies with topics to ensure only the subscribers that sent their request (with their topic as their identifier) would receive the correct reply. This takes care of the routing issue, but since the publisher is unaware of the subscribers, it knows nothing about clients that disconnect.
PUSH/PULL - Seems to be able to handle the message queuing issue, but looks like it won't support my plan of having messages sent to specific clients (based on their ID, for example).
ROUTER/DEALER - Design seemed like the solution to both, but all of the examples seem pretty complex.
My thinking right now is continuing with PUB/SUB, try to implement some sort of heartbeat on the client end (allowing the server to detect the client's presence), and when the client no longer sends a heartbeat, it will stop sending messages tagged with its topic. But that seems sub-optimal and would also involve another socket.
Are there any ideas or suggestions on any other ways I might go about implementing this? Any info would be greatly appreciated. I'm working in Python but any language is fine.
To prepare the best proposition for your solution, more data about your application requirements. I have made a little research about your conditions and connnect it with my experience about ZMQ, here I present two possibilities:
1) PUSH/PULL pattern in two direction, bigger impact on scalability, but messages from server will be cached.
Server has one PULL socket to register each client and get all messages from clients. Each message should have client ID to for server knowledge where send response.
For each client - server create PUSH socket to send responses. Socket configuration was sent in register message. You can use also REQ/REP pattern for register clients (assign socket number).
Each client has own PULL socket, which configuration was sent to server in register message.
It means that server with three clients required to (example port numbers in []):
server: 1 x PULL[5555] socket, 3 x PUSH[5560,5561,5562] sockets (+ optional 1 X REQ[5556] socket for registrations, but I think it depends how you prepare client identity)
client: 1 x PUSH[5555] socket, 1 x PULL[5560|5561|5562] (one per client) (+ optional 1 X REP[5556])
You have to connect server to multiple client sockets to send responses but if client disconnects, messages will not lost. Client will get their own messages when it reconnect to their PULL socket. The disadvantage is requirements of creating few PUSH sockets on server side (number of clients).
2) PUB/SUB + PUSH/PULL or REQ/REP, static cocket configuration on server side (only 2), but server has to prepare some mechanism for retransmit or cache messages.
Server create PUB socket and PULL or REQ. Client register it identity by PULL or REQ socket. server will publish all messages to client with this identity as filter. Server use monitor() function on PUB socket to count number of connected and disconnected clients (actions: 'accept' and 'disconnect'). After 'disconnect' action server publish message to all clients to register again. For clients which not re-register, server stop publish messages.
Client create SUB socket and PUSH or REQ to register and send requests.
This solution requires maybe some cache on server side. Client could confirm each message after get it from SUB socket. It is more complicated and have to be connected with your requirement. If you just would like to know that client lost message. Client could send timestamps of last message received from server during registration. If you need guarantee that clients get all messages, you need some cache implementation. Maybe other process which subscribe all messages and delete each confirmed by client.
In this solution server with three clients required to (example port numbers in []):
server: 1 x PUB[5555] socket, 1 x REP or PULL[5560] socket + monitoring PUB socket
client: 1 x SUB[5555] socket and own identity for filter, 1 x REQ or PUSH[5560] socket
About monitoring you could read here: https://github.com/JustinTulloss/zeromq.node#monitoring (NodeJS implementation, but Python will be similar)
I think about other patterns, but I am not sure that ROUTER/DEALER or REQ/REP will cover your requirements. You should read more about patterns, because each of it is better for some solutions. Look here:
official ZMQ guide (a lot of examples and pictures)
easy ROUTER/DEALER example: http://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html
Case:
A WebSocket connection have been established between the client and server endpoint.
Now I have the network connection go down (for example the ADSL dies), after 10 min I recover the network, I find that the client and server are still able to communicate with each
other. Why?
Note:
The client was developed with Java-WebSocket framework, and the client did with ws4py.
1 - If they did not try to exchange any data and only the connection (not the endpoints) between them is down, this is normal behaviour.
2 - If the websocket connection ended, Browser may have re-established it without you knowing about it. I just checked that this is not normal behaviour. But maybe there is some parameter somewhere :-)
If I am not wrong, to have a push technology the client ( say browser ) also needs to run a small web server which is listening on some port ( say ijetty runs on 8080 ). Now when the actual server comes to know about any event, it sends the event to client. This way there is no PULL mechanism involved at all. Is this right ? OR there is a persistent connection involved and server sends the data on that connection whenever the event happens. My question is : in the former case ( if it is true ), how does server know about client's IP ?
WebSockets working with socket based on TCP connection, basically the client make a request for connection to the server with a challenge, websocket version, ip and more data, then the server decrypts the challenge and return his result back to the client, this process called Handshake.
If the handshake is approved, the connection is made, the socket connection remains open between the client and the server, heartbeats will be sent from the server to the client like a ping to check if the connection is still open.
read this wiki to find out more:
http://en.wikipedia.org/wiki/WebSocket
I've developed a web-based application in which a signed in user should send a message to the server telling he is still online every 3 seconds. The message is then processed by the server and a stored procedure is called in Mysql to set the user's status to online.
I've looked in to similar issues in which Comet and Ajax are compared (here or here) but considering that 3 second delay is acceptable and maximum users of 1000 are online in the system, is using Ajax a wise choice or Comet should be used?
For this kind of feature comet is more appropriate:
Your clients send messages (i'm online)
Your server broadcast the processed message (user X is still online)
In an ajax way you are only serving messages to server.
In order to get the "broadcast effect" in an ajax way. You will end up doing something similar to comet but with less efficient bandwidth.
Ajax:
Client send server - i'm in
Server process
Server send back to client list of user in.
In this case every client ask every 3 second the database for the COMPLETE "in" list.
In comet:
Client X send server - i'm in
Server process
Server send back to client S that user X is still online
In this case every client tell the server every 3 second that he is in.
The server send back to every connected client ONLY that x is still in
Comet is just the technique to broadcast back and push messages to client
Ajax is the technique to push client information to the server without having to refresh all the page.
Quoting wikipedia:
http://en.wikipedia.org/wiki/Comet_%28programming%29
Comet is known by several other names, including Ajax Push, Reverse Ajax , Two-way-web, HTTP Streaming,and HTTP server push among others.
So go comet :)
If you do not broadcast anything, then simple Ajax is the best option
In this particular case, since you do not need to send any information from the server to the client(s), I believe Ajax is the more appropriate solution. Every three seconds, the client tells the server it is connected, the database is updated, and you're done.
It could certainly be done using Comet, in which case you would basically ping each registered client to see if it is still connected. But, you would still need to run a query on the database for each client that responds, plus you would still need the client to notify the server on its initial connection. So, it seems to me that Comet would be more trouble than it's worth. The only thing that might make sense is if you could ping each registered client and store the responses in memory, then once all clients have been pinged you can run one single query to update all of their statuses. This would give you the added bonus of knowing as soon as a client disconnects as opposed to waiting for a timeout. Unfortunately, that is beyond the scope of my expertise with Comet so, at this point, I can't help to actually implement it.