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.
Related
i am developing a chat application for local environment where our office employees can chat easily so here I am getting some conflicts when I am trying to send message over the IP but there IP being change dynamically so how can i resolve it .
First of all, I recommend using a well established solution like a local Jabber Server installation and using a client that supports the required features.
If you really want to pull this off on your own, you'll need at least a central controlling point (Server) to abstract Users from their Endpoint.
Configured user would then have to login to that server to signal they are ready to receive messages. Doing this, you have the momentarily correct IP that you can then use to relay messages or to give to other clients wanting to send to that user. Also consider that users may want to use more than one client (they have 2 PCs?). You probably wouldn't want to bind one user to one client device.
Also note that you will have to create a decent protocol for all this. This can be quite tedious if you want similar features to for example Skype Chat or ICQ, or some derivate of XMPP / Jabber.
This leads me again back to my first suggestion: Better use something that already exists. Installing and configuration of that can already be effort enough. Coding all that by yourself, though will take way more effort.
And I didn't even go into status/statusmessages, groupchats, sending/sharing Files, sending messages while User is away/offline ...
I've been through different questions about this topic, however, none of them have cleared my doubts on the best approach notifying the client side of a server-client IM app.
The Problem:
The whole problem is how to notify the client application of updates. I've alread seen the following approaches:
Clients keeps checking for updates: From time to time, client app performs a check in the server to see if there are updates for that specific user;
Problem: it is not performatic at all. Suppose you have one million users and each one of them checks for new updates every second. Serve would have to deal with one million requests per second. Wont work.
Client app opens a socket: The client app opens a socket and sends its address to the server. Server, by its turn, persists this information and connects to the socket whenever it needs to notify the client of some update.
Problem: Often the client will be connected to a NAT, so, the IP it has access to is in a non-visible range. In order to send messages to this client, a port forwarding in the NAT would have to be configured, which can't be done.
Despite of the technology, I think this approach will always be used, however, I have no idea how the problem described above can be solved.
Google Cloud Message (GCM): use the GCM service to notify the client of any update. Problem: It does't seems right to use a third server to handle the IM and it raises concerns about the scalability of the system. When the number of messages and users increases exponentially, it seems that the service will go down. Despite that, it seems that passing the information for two servers before delivering to the targets just adds bottlenecks in the process.
A combination of 2 and 3: uses GCM to reach the client when the last persist addres is no longer available.
Problem: same as described in 2
XMPP: I've seen many answers indicating the use of XMPP for IM applications, however, XMPP is a protocol - as per what I've foun in the web. I don't see how it can solve the problem described in 2 for instance.
Given the options above, can someone indicate me what line should I try to go for? Which one of these approaches has the best chances of success?
Thank y'all in advanced.
Use Google Cloud Messaging. Opposing to what you stated this service is built to scale to billions of users it will generally not introduce performance bottlenecks.
What you basically want to do is to use the messaging service to wake up devices. If you insist you can then still use your client server approach and thus your own protocol to have the client lookup new messages from the backend.
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).
Purpose:
I'm trying to make a real-time web service in Java. When there're changes in database, the data in clients(probably Android client) will be changed automatically without refreshing.
Platform:
I'm using Tomcat 7 container and Axis2.
Problems:
I'm stuck in the way to approach. I've realized that there were 2 ways:
1. When the data in server changes, notice to all the clients. Web-service allows us to do this, but I don't know what clients I have to inform!
2. Clients connect to the server, keep the connection alive and whenever there's a change, update data. However, if the client is the handheld, it will consume much power and data exchange over 3G network.
I know that's a complicated problem. So I just want to ask if there is an efficient way to approach? And if possible, anyone can give me one example of realtime web service like this?
I've searched over many pages, but nothing's helpful. Can anyone give me some suggestions? Tkx!
Is it a requirement to use webservices or Axis? Otherwise, you might be interested in WebSockets. These are connections over plain HTTP that provide two way communication. Your clients will connect to your server, and as soon as new data is available your server can push data to every connection it knows of, thus informing all clients that are connected.
I need to write an application in java which communicates with a web server.
I know how to do that, using PHP, but I'm afraid it won't cut it in this one.
Here's my situation.
I have multiple clients, when one of them sends a specific message to the server (so far, no problem on PHP), I want it to send a certain message to all other connected clients.
The problem is, I could hardly find any information regarding server socket in PHP, which led me to believe this isn't the proper way of achieving that. I'm using a paid hosting (x10premium) to host my servers so far, so I was thinking of doing it with this one, however, I'm not sure it's even possible with PHP.
At the moment I'm having each of the clients periodically check with the server if he received a message from any of the other clients, but I don't like this solution...
I hope someone could point me to the right direction. I don't know too much about Ruby and other languages which are used to do stuff like that, But if necessary, I would gladly learn it.
Thanks in advance
EDIT:
Forgot to mention, the server (currently the PHP) would also communicate with a MySQL table. If it matters.
This is a good example of PHP socket server/client:
http://tech.navarr.me/2010/07/how-to-create-a-socket-server-in-php.html
You could do it just like with JAVA, but remember that PHP does not support multithreading or multiprocessing so if 10 clients connect at once to your server, you will process them one by one, so eventually 1 will have to wait for the other 9 to finish - everything, database and connection overhead.
If you do it with JAVA or Python for example, you could handle each request in separate thread so that DB & Network communication overhead is handled simultaneosly.
Python has build in socket server components and nice and easy to use mysql component, that would make it a breez to achieve this, without even having to understand threading at all.
For the python socket server see here:
http://docs.python.org/library/socketserver.html
Basically you just define a function that will be executed for each new client connection and tell the server to serve_forever() - until it dies, it will do what you want.