Grizzly Comet push to only one client - client

I would like to know, if it is possible to push some dama via Comet to only one client (more clients connected).
Let's say I have 400 clients connected to server and only 20 of them needs to get refresh command. How can I send this command only to those 20 clients (I have their IPs on server side, so I know which one they are).
Is this possible and if yes - how?

When you call context.notify(), you can pass in an object that contains both the payload you want to send out and the list of IPs that should get it. Then in your CometHandler, you can simply check the requests remote/client IP against that list. If the list is empty or contains the IP for that handler, send it. Otherwise, ignore it. When you create your handler you'll want to pass in or attach the necessary info to do that check but that's a pretty simple affair, too.

Related

Dispatch websocket connections based on subprotocol

is it technically possible to run multiple websocket servers that listen on the same port and dispatch using the subprotocol name ? E.g. a process that would handle "protocol1" and another that would handle "protocol2". My guess is that it is not, since TCP cannot conditionally accept a connection, so the only way would be some kind of socket ownership transfer.
Actually, it would be possible to achieve by using a Proxy as a load balancer, which isn't something I tried managing before... So I can't post a demo configuration file.
I know Apache will allow you to decide on a proxy path according to the request headers - this means you can check the sub protocol before forwarding the data... But this is mostly a conceptual solution I never tested.
This question is tagged WebSocket++, so I will answer from the context of that library.
Maybe, depending on exactly what you mean. WebSocket++ will let you build one program that can internally handle multiple subprotocols. WebSocket++ has a pre-acceptance hook called the validate handler. In the validate handler you are presented with a list of subprotocols the client has requested and may choose which one you want to accept (or none if your server doesn't support any).
This isn't the same as conditionally accepting the TCP connection itself, but does let you conditionally accept the WebSocket connection. Once accepted your app can inspect the selected subprotocol in the open handler and choose which logic to use to process the connection.
A WebSocket++ based program can juggle multiple connections on multiple subprotocols simultaneously. If you truly want multiple independent processes handling each then the best WebSocket++ will be able to do is act as a proxy for those connections.

ZMQ: Multiple request/reply-pairs

ZeroMQs Pub/Sub pattern makes it easy for the server to reply to the right client. However, it is less obvious how to handle communication that cannot be resolved within two steps, i.e. protocols where multiple request/reply pairs are necessary.
For example, consider a case where the client is a worker which asks the server for new work of a specific type, the server replies with the parameters of the work, the client then sends the results and the server checks these and replies whether they were correct.
Obviously, I can't just use recv,send,recv,send sequentially and assume that the first and the second recv are from the same client. What would be the idiomatic way to use multiple recv,send pairs without having to handle messages from other clients inbetween?
Multiple Request/Reply pairs can be made through the use of ZMQ_ROUTER sockets. I recommend using ZMQ_REQ sockets on the clients for bidirectional communication.
If you want to have multiple clients accessing a single server you could use a router socket on the server and request sockets on the clients.
Check out the ZMQ guide's section on this pattern:
http://zguide.zeromq.org/php:chapter3#The-Asynchronous-Client-Server-Pattern
All the clients will interact with the server in the same pattern as Pub/Subs except they will all point at a single server Router socket.
The server on the other hand will receive three messages for every single message a client sends. These parts represent:
Part0 = Identity of connection (random number of which client it is)
Part1 = Empty frame
Part2 = Data of the ZMQ message.
Reference:
http://zguide.zeromq.org/php:chapter3#ROUTER-Broker-and-REQ-Workers
The identity can be used to differentiate between clients accessing on a single port. Repacking the message in the same order and responding on the router socket (with a different data frame) will automatically route it to the client who sent the message.

Winsock Array with data arriving simultaneously stops sending data to clients

I've been searching online for days now and I can't find anyone who has this same problem with the VB6 Winsock. So here's my problem, I have a server with two winsocks in an array. I then have two clients each with one winsock control. Now the I have it set up is that the server first sends data to client A. Then client A receives that data and sends its own data back to the server. Then the server sends data to client B, once client B receives the data, it sends its own data back to the server. So data is being sent from a client to the server, then from the server to another client, then back to the server, and then on to another client. I did it this way because when I tried doing it the way I really want it to work, I was having problems. So I had to set it up this way in order to ensure that only one client is sending data to the server at any one time. This process works perfectly, however I want it to work in a different way, since as you can image, the more clients there are, the longer the delay in data transfer between each client and the server.
So what I really want to do, which I can't get to work, is have the clients send and receive data to the server whenever they want. That is, client A sends data to the server, and then the server sends data back, all while client B is doing the same thing. When I do this, even though I have a winsock array on the server, I run into a problem. When client A first connects, it begins sending and receiving data to the server. But once client B connects to the server, all communication between client A and the server stops, and only client B sends and receives data to the server. Now I've done some tests and client A remains connected to the server the whole time. But for some reason, it seems that if two clients send data to the server simultaneously, only one data arrival event fires, even though each winsock is on a different port. I have not installed VB6 SP6 yet, as I'm not sure this will fix the problem.
So I really do hope someone will read this and explain to me what it is that I'm not understanding or what it is that I'm doing wrong.
If you search for Microsoft KB articles on the Winsock control you will find a long history of flaws and bug fixes. There is absolutely no reason not to install SP6 before even attempting to use VB6, since a vast number of issues were resolved over time.
Once you've done that (and only then) is it really worth talking about problems of the sort you describe. At least it eliminates a significant number of known problems, and then it might be worth discussing your code.
Are you using none blocking sockets? I guess you should.
You should probably create a thread for each incoming connection.
So the main loop should act none blocking and create a thread for each incoming connection, that receives the data and sends the answer.

How to send data to client browsers when a server side change occurs

I have an intranet based CRM application developed in CodeIgniter 2.1 where the application is running on a local Apache server and around 20 clients are accessing it over LAN. This is to be connected to a call center setup where the call center application (running on a separate server) will do a HTTP post with caller's number as well as terminal number of the agent where the call is arriving to a URL of my Codeigniter application. I am using this data to populate a database table of call records.
Now from the terminal number (each terminal has static IP, and a session in Codeigniter is linked to IP as well) I can find out which user (login session) of my application is about to receive the call. I want to find a way out how I can send data from server side (it will be regarding the call like the number who is calling, past call records etc.) to that specific user's browser via AJAX or something similar? The agent's browser needs to display this information sent from server.
Periodic polling from browser by jquery etc. is not possible as the data needs to be updated almost instantaneously and rapid polling up to this extent will lead to high CPU usage at client end as well as extra load on network.
P.S.: I only want to know how to modify the browser data from server end.
In AJAX, asynchronous request/response doesn't involve polling; there's just an open TCP connection and non-blocking I/O. The client makes a request but returns immediately; when the server sends the response, the client is notified. So you can achieve what you want with AJAX's XMLHttpRequest without polling[1]. All you need is a url from which to serve your notifications. You could have one request thread and a general dispatch method, or different urls and different threads for each, depending on how you needed to scale.
[1] Well, to be honest, with very little polling. You'd really need to establish what the session/global timeout was and reissue requests within that time limit.

Ajax vs Comet (not a chat application)

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.

Resources