I have several PC's on each of them I set small swing application that get data with JSON request to one web server. Can I receive the data from web server without to send request to the web server, with other words can the Web server send the data without the Java application to ask for this?
If you have enough server resources
you can consider usage of websockets.
Every PC can open a socket to the server.
When you open the socket you need to send to the server, the pc's unique ID.
Then you need to store this ID in some database or file that will contain all online pc's and sockets .
Then the Server will be aware which pc's are online and which socket to use to communicate with this pc. After this you can send whatever information you need to this PC depending on your application.
This can be implemented in several ways. One common way would be to open a connection and do blocking read in the client application. On receiving something it will look like push from the server. Then you process the push and do another blocking read.
Another option would be doing regular checks if there is something for you on the web server. You set the retry interval frequent enough so it will look like real time push from your app point of view.
If you use HTTP i think the smartest way is to drop the realtime requirement and use a thread that polls the server every 5 seconds. Keeping a HTTP Connection open all time is expensive as it blocks a request processor thread and limits the amount of clients you can have.
You might also consider moving to something like a registration mechanism if you really need near-realtime updates which is often not the case. You would have to open a Server on the clients and have the server push the updates after clients registered their Address with the server.
Related
I want to monitor firebase client connections from my java server.
I have found a lot of examples on how to use onDisconnect from the client side (iOS), and it works great.
But is it possible to monitor client connections from a java server using the java server sdk? I simply want my server to know about user disconnects, but without the client having to 'tell' the firebase database that it has connected/disconnected.
The reason for this is mostly security, and a wish to trust the client as little as possible to do important tasks. Ideally most of my data should be 'read only' from the client, except for some 'write only' request queues consumed by the java server.
From the firebase java server documentation: https://firebase.google.com/docs/reference/serverreference/com/google/firebase/database/OnDisconnect
The OnDisconnect class is used to manage operations that will be run
on the server when this client disconnects. It can be used to add or
remove data based on a client's connection status. It is very useful
in applications looking for 'presence' functionality.
It seems like what I want to do is possible and supported, but I'm having a hard time figuring out how to make my server monitor 100-1000 connections realtime.
Lets say I'm monitoring a database reference that I know clients are monitoring. In that case none of the options to 'remove on disconnect' or to 'set on disconnect' are useful.
Thanks a lot for reading this, I'm REALLY loving firebase right now, just a few more issues to figure out :-) Also sorry for my english, I'm not a native speaker.
I currently am developing a semi-simple chat app. I want the user to be able to communicate with one other person in a private chat. Just plain text will be sent. Currently my system calls php scripts from a webpage, passes in parameters and then parses the data returned. I have it so that the client sends the message, which calls a send message script on my webserver, the script then makes a message file on the webserver and then returns a success or failure back to the client. Then for the client to view this message, it would have to call a script that checks the server for a message file with a message for him. If it finds one, it sends the message back, if not, it sends a response about not having messages.
This technique works perfectly besides the fact that the client either would have to manually refresh to check to see if he had messages, or a background thread would have to refresh every few seconds. That would be fine, however that would use data if the user was on a mobile network. Not to mention the kind of resources a background loop would pull if it was refreshing at a speed that would be convenient.
So, I decided on a second idea, this would be a server programmed in Java, which would communicate over sockets. The user would send the message as a packet over the socket and the server would check to see who it was meant to go to. If the person is online, it passes the message along to that user. However this method requires a constant connection between the client and the server and that is unreliable because what if the user is in the car and data cuts out. Or some other situation where the connection gets severed. Then it would throw errors and have to reconnect.
Anyhow, my question is which technique is better. Or are they both terrible? If so, what is the correct way of doing this? Thanks in advance.
AngularJs and Ajax will be the perfect solution for you , try to learn
for actually real time messaging Use AngularJs
If the amount of data is very less ..say 20-25 messages per day...you can REST APIs on your server to transfer actual text messages and Google Cloud messaging for pushing notifications..Recently I followed this approach to develop private chat for one of my friend.
when building a server, one sometimes performs asynchronous tasks from client to server (which responds to client in asynchronous time),
or the server needs to send the client a message
now if the client is listening at all times (meaning polling) it takes a lot of resources which is problematic
here is where I assume the operating system steps in and assumes the role of polling for the appropriate port, and letting the application know using the appropriate event (the application subscribes using the OS API)
am I right in my assumptions?
how do I subscribe to a port using the OS's API? (lets say android for the sake of argument)
how is a message from server to client work exactly?
and how does the server know the client's IP at all times?
I have seen many questions in the subject, but wasn't able to figure out the big picture
Edit:
I am using GCM in android, but have seen other apps that does not use it and still manage to do it right, also it's a more general question as to what is the right approach in java VS. any operating system it uses (ubnutu, windows, android, etc.)
Totally right - polling is typically a waste of resources. Until recently, many apps would either keep a socket open and poll every few minutes to keep it alive, or make periodic HTTP calls to a server.
Nowadays, Google Cloud Messaging is used by most apps to push data instead of constantly polling. As you correctly guessed, this is implemented by maintaining a persistent connection with Google's servers. The advantage of this is that it's very efficient for battery life, and that all apps can use this one resource to send push notifications, instead of each app having to poll a different server or create its own persistent connection.
The idea is that you send requests to GCM from your server (this can be in response to user activity, etc), which sends it to all of the client's devices. You can either send a message with a small payload (up to 4kb) or a "send-to-sync" message, which tells an app to contact the server (e.g. to sync new data from the server after user changes).
here is where I assume the operating system steps in and assumes the role of polling for the appropriate port, and letting the application know using the appropriate event (the application subscribes using the OS API)
GCM pushes messages to clients, so there isn't active waiting like you'd see in a simple polling system.
how is a message from server to client work exactly? and how does the server know the client's IP at all times?
There's no need for servers to know the client IP, as any online android device will typically maintain a connection with GCM. Targeting specific users is done via User Notifications.
(Oh, and I realize that your question is more general than just Android, which I have more experience in, but iOS has a similar system in place. Some developers I've met like to use Parse for managing push notifications).
I have this task that I'm undertaking where I would be reading data from a device and make it available over a web service. The data is read 4 times a second. I want the web clients to be have an open HTTP connection and get the device readings as a stream using chunked transfer as long as the client keeps the connection open.
As a proof of concept, I want to start with a service that constantly generates a random number, 4 times a second, wraps it in json and stream that to clients. I'm trying to model it loosely based on twitter streaming api.
I'm using restlet 2.1.2 to create that webservice but I'm not sure which Representation I should be using to achieve this. I tried searching for this but didn't find anything useful. Could someone point me in the right direction as to what I should be using and maybe some examples, perhaps.
Thanks
To achieve what you are trying to do, I'd use the WriterRepresentation (but see my answer to your other question), but I'm quite sure that you are going in the wrong architectural direction.
Indeed the following image from the documentation you linked
shows how even the Twitter streaming api is not intended to be connected by users, but by background processes that download messages in a store accessible by the HTTP. Users poll only the HTTP server, that reads the messages from the store and sends the back to the clients.
As a disconnected protocol, HTTP enable massive scalability that would not be possible otherwise. If each client establishes a persistent TCP connection backed by a dedicated server thread, you will rapidly exaust server resources! Moreover any HTTP proxy between the User Agent and the server could cause unexpected behaviours.
Thus, if you are bound to the HTTP protocol, the User Agent should poll. You can reduce the network load with headers like Last-Modified/If-Modified-Since or Etag/If-None-Match.
However, if you can adopt a different protocol, I strongly suggest to try a service bus over a connected TCP protocol.
I think I'm just missing a little detail that is preventing me from seeing the whole picture.
I have a web application which use ajax request every x time to update client with new information or tasks.
I also have a long running process on the server which is a java computation engine. I would like this engine to send update to the client.
I am wondering how to migrate my web app to using websocket. Probably phpwebsocket or similar. Can my server 'decide' to send information to a specific client? It seems possible looking at the php-websocket.
Can my java backend long process use the websocket server to send notification to a specific client. How? well I can say that my java app could use a class that could send over websocket instead of http.
But how the websocket server knows to which client to send the 'info'. I am puzzle by all this. Any document that explain this in more details? It seems that the websocket could create an instance of my web application.
Thanks
Your server, which will have an arbitrary number of active client sockets, decides which ones to write to (possibly in response to input from the user).
phpwebsocket (which is still very rough around the edges) has a User class with $id, $socket (this is the underlying TCP socket), and $handshake fields. You could extend that class with additional metadata about the User (e.g. a computation identifier). Or you could use an array mapping from computation id to User.
Perhaps when Java computation n finishes, you can look up the socket associated with that computation, and write to its socket.