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.
Related
I am using Play Framework 2.6 with Java to implement a server for a REST API. Some REST calls include uploading an image to the server. The server has to process the image and should inform the client when it is done. Some images may be analyzed for 10 minutes or more, so the client REST call cannot wait for the answer. I am thinking about informing the client that the image is ready via Server Side Events (SSE) or WebSockets (WS), I prefer SSE.
I know the Play Framework example at https://github.com/playframework/play-java-streaming-example , but it is too simple since it just sends an event every 100ms to the client.
I also know the example at https://github.com/playframework/play-java-chatroom-example which demonstrates a chatroom which only sends events when a client sends a message. But (for me) there is too much "black magic" going because just a bunch of lines connects all the clients. The problem here is, it is broadcasting the messages, there is no control which client receives which message.
What I am really looking for is:
Tracking my clients (for example in a HashMap) so I can find them by a session ID and if there is message for a specific client, I pick this client from my Map, sent a Server Side Event to inform it that the image is processed. The client can then make another REST call to get the result.
Are there any examples or source code snippets to achieve that?
Looking forward for any help!
Thank you,
schube
I have a web-service on my server that pushes the xml data to the clients that are communicating to it over internet.
In these cases we have challenge to receive acknowledgement from the
client.
Specific case like, once client has received the data and before
sending the acknowledge, if the communication channel goes down.
Example:
In case of the software updates on clients over internet, how the server makes sure every thing is processed fine.
If you want to go on the "push" path, and you absolutely must know if the update was succesful, then you have to build your service and clients in such a way that you do know.
Basically what you need to do is build a small protocol so that information is transmitted no matter the failures of the communication channel. This means two things:
Your service does re-transmissions;
Your clients can deal with duplicate messages;
For example:
service pushes a message, client acknowledges => all good;
service pushes a message, the connection goes down, the message is lost. The client does not acknowledge since it never got the message => service pushes that same message once again at some later time. Now hopefully you get to case 1.
service pushes a message, client acknowledges but the connection fails and the service does not receive the acknowledge => similar to 2, so the service pushes that same message once again some later time and now the client receives the same message twice. It must ignore the second message but still needs to send an acknowledge so the service does not send it a third, forth, ... nth time;
And so on and so forth...
This is a high level description of what TCP does, for example. TCP is a reliable protocol over an unreliable network. It handles dropped packets, duplicated packets, etc.
Now, that would be pushing. A more simple alternative would be to use "pull" instead. The clients periodically pull the updates from the server. This is simpler to implement (the download is succesful if it worked, otherwise you try again later) but it's not without its gotchas, like for example:
controlling when clients start to pull data from the service. You can't just have them all update at the same time or you might overload the server. Clients should first ask the server if it's OK to update now or comme back later when the service is not so busy;
are you downloading upgrades in the background, from user devices? Data charges might apply so maybe it's better to ask the user if it wants the update now or later instead of doing it behind the scenes;
updating in the background, even if there is no problem with data charges might still consume bandwith when the client needs that bandwith for something else;
And so on and so forth...
The thing is this is a large topic, with general solutions that might not apply given particular situations. But it is not a new topic. Others have had these issues before. Consider for example Windows updates, how each PC's OS updates itself. Something similar happened a while ago when thick clients needed updates. The world moved to thin clients but now thick clients are making a comeback. Have a look at how these issues are solved, you will find usefull information online.
I do not think there is a way to do that. I believe the reason you are asking is for the following reasons:
1) If you are asking because you are sending a lot of data and your client deny receiving it, perhaps you can paginate it. That way you will know when the last page was accessed. You can even go one step further and just put very little data on your last page, that way you are sure that the last page is called.
2) If you are genuinely concerned about ensuring that they receive the entire data. How about suggest they access a 2nd web service which contains the checksum for the data, and suggest that they compare it.
Assuming that your web service is RESTful, your server should be stateless. The client should make sure it receives the data properly.
You could define a service to get the hash value of the data, followed by the request to receive the data itself. The client can check after the download whether the hash value of the downloaded data corresponds to the value received by the first call.
Amongst others, you could use MD5, SHA-1 and SHA256 in standard Java, as described in the Oracle documentation. This will calculate the hash value of the data from the server side.
Assuming you use Javascript from the client side, there are many possibilities to calculate the hash code using the same algorithms (jsSHA, for example).
I hope it helps.
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.
I'm currently searching for a way to transfer a String array from one android to another through the internet (assuming both devices are connected to the internet).
There's the possibility that one (or both) of the devices is connected to a network which is provided by a router, therefore using the IP address isn't practical (as far as I know).
I've stumbled upon an idea which suggests using Email to transfer the data. but, if I'm not wrong, that will force me to translate the array to an Email, send it, and undo the translation (to get it back to a string array form).
I would prefer a solution that will transfer the String array as it is.
Is it possible? Is there a better way to executed this process?
(I'm developing in Java on the Eclipse IDE)
I'd be glad to hear your Ideas! (:
Several options:
Device A sends an HTTP Request to the web server, Device B regularly gets data( using timer ) by sending request to fetch message sent to him. But this is not really real-time.
Device A sends an HTTP Request to the web server, The Server Pushs to Device B. You need to implement Push using Comet or GWT.Comet wiki
Implement XMPP Messaging. Device A send an XMPP Request, Server push to Device B. XMPP wiki
If I were you, I will do no 3. Since your explanation sounds more related to real-time messaging case. Please forget thinking about using email.
I have a school project in which I have to implement a chat application, whose server will be a java web service.
The problem is that I've always thought of a web service as a way of calling remote functions, and I have no idea how to keep a "session" active on the web service, nor how to keep track of all the people currently in chat, rooms etc.
To the best of my knowledge, a chat server is supposed to know its clients after an initial connection, and send every client message to all clients. This definitely calls for some sort of session maintenance. I think the right way to do this is as follows:
Client calls web service 'handshake' and provides some minimal identification details.
Server returns an acknowledgment that includes a unique client identifier.
Client calls web service 'message' and sends a new message, together with its identifier.
Server identifies client by the identifier, distributes message to all clients.
I'm not really sure how the message distribution should work, as web services are essentially a pull-service and not push. Perhaps the client should expose its own web service for the server to call.
Hope this helps,
Yuval =8-)
You could consider implementing a COMET solution. This will effectively give you push communication, thus eliminating latency, a VERY nice feature for a chat application.
If you want to go for the gold, consider implementing more advanced features:
spell check
URLs/email addresses converted to links automatically
separate chat rooms
moderator functions (terminate chat, kick user)
event info like "User is typing..."
statuses (available, busy, away...)
avatars
...
I don't know Java so this answer will be language agnostic.
In my opinion the simplest way to do this without running a process on the server would be to store all your data in a database.
Here is a short list of the basic things that will need to be done:
Need a table with a list of users and passwords for authentication
Need a table for the currently logged in uses
A. needs a time stamp field of the last contact
When a users does something update the last contact field to the current time
If the user' last contact time is > current time + 2 minutes then they are logged out
client side application will need to send periodic messages to the server to say "Im still here"
You'll need to find a way to determine when a message has been sent and when to update the client's display that a message has been received, this I will leave to you.
If you still need some help here is an AJAX/ASP.Net chat app that should (I didn't look at its source) work much the same way.
I wrote a chat engine which had a service in the background and everything stored in a database, an input form frame and an output frame which received the html stream.
If you want to skip the service part and only implement via a web service, you need to implement at least two operations: Post for inputs, and GetLatestChanges to receive the chat's output, which translates into HTML using some Javascript magic.
Of course you need to keep track of rooms, users, messages, which user receives which texts etc, as sketched by Unknwntech.