Sorry for trivial question but I'm planning to create server application, but first I need to write down all possible (outline)
server scenario; I'm puzzled with one question of how server informs or gets state of client and notify it to other already connected to this server, clients.
PS After authorization we already be aware of client's state but what of further state of client,
How server knows about this, I think it's server's initiative to do that if yes HOW?
Generally, it's the client that should inform the server when something changes, otherwise you're wasting traffic by constantly polling the clients even when nothing has changed.
But this depends on what it is you're doing. For real-time scenarios, for example with a multiplayer game, the clients could constantly send their state several times per second even if nothing has changed. Likewise, the server would send the current state to all clients regardless of whether there were any changes or not.
Related
I’m bulilding a web app that requires communication between clients. For this I’m using socket.io. Some data however has to be updated regularly in the database.
Some of them not that often (preferences, on button click) others in every second for example a timer value. This can not be calculated because the timer can be paused.
Right now whenever a client emits an event, it also makes a request to the backend to updated the database. I was wondering if it would be a good idea to have the socket.io server update the database so the clients would only have to take care of the socket communication? It seems to me that having the browser do a request to the backend is a bit resource heavy and takes out a bit from the advantages of the socket based communication
Edit: the back end of the app and the socket server are two different servers but physically they are on the same machine so their communication could be faster
the main point of using socket.io is that it allows you to push data to clients and clients do not need to check your server constantly to get the last changes, and providing a low-overhead communication channel between the server and the client.
you can call an API and also emit data and many other things on user click in your application.
it is a good idea to have the socket.io server update the database and you can also authorize each socket, save client sockets information and ...
As I understand it, Websockets use a Ping to detect that they are still connected. Except of course Chrome which leaves it to apps to do the ping themselves.
I'd like to understand if its possible for a connection to become unstable between pings such that a frame of data is not received... but to stabilize again by the time the next ping is sent. In other words: is it possible to have an apparently good websocket connection, but for data to fail to arrive?
Question relates to Is it possible to miss websocket events which remains unanswered and side-tracked into long-polling and socket-io.
Thanks!
This is heavily dependent on the client software (browser) that you use.
The websockets depend on a TCP connection which will make sure the message arrives to destination. Except if the network connection is down, of course.
However, some clients (browsers) will suspend the inactive tabs and will not process the events. If your page is inactive, it "may" fail to send data to the server because it will not be executed at all. On the other hand, it "may" also fail to receive data because the handler will not be executed at all.
Meanwhile, even if inactive, the machine will still receive the ping packets. So it is really about whether or not your client software gives it back to your code or not.
I'm evaluating some messaging libraries and protocols (e.g. ZeroMQ, WAMP). One of my main requirements is that sending messages from client to server and vice verse (two way communication) must be absolute safe with respect to client/server crashes. This means to me that e.g. the client must continue sending all not delivered messages after a spontaneous reboot. So the library should implement some kind of file based buffering. Is there anything there I can use out of the box?
[EDIT]
Some note on my use case:
In my scenario there are around 1000 clients communicating with one server. There is no direct client to client communication required. But I need a two-way communication, so both, the clients can push some data to the server and vice versa. The clients are connected via 3G mobile network. Both, client and server are written in C#. I focused on using ZeroMQ, Apache Thrift or WAMP. But one of the main requirements is to ensure asynchronous but safe messaging with respect to system crashes. So when the client starts an asynchronous data push to the server, and it will crash before the message can be delivered to the server, it is required that the client will continue sending the message after a reboot.
You might look into the Apache.org's Kafka project.
The problem is harder than it looks, and most people don't want to pay the price to make it happen.
Also, there is a UX issue with old queued up messages replaying without the user's understanding.
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.
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.