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.
Related
I am developing a servlet based application. One situation is that a client requests some data from a database which is sent back in the form of html. The client will modify this data and then sent it back to the server. Now the twist starts. There is not a single client. So multiple clients can request the same data. So what I am doing is that when the first client makes a request, this request is stored somewhere so that when the next user makes the same request he is denied the data.
Now suppose the first user gets the data and 2nd is denied. Now while the first user is on the html page which allows him to modify the data. I want to send continuous javascript async post requests at a fixed interval to inform the server that the client is active.
At the server side I need a thread or something which can keep waiting in a loop for the javascript async requests and if the request is not received within the fixed time then the thread removes the saved request so that future requests to the data will be accepted.
I have searched the entire day and looked at things like async servlets, ServletContext listener and scheduledExecutorservice. I dont want to use scheduledExecutorService as it is invoked at app startUp which I dont want to do since this specific situation is a minor part of the code and to handle it I dont want something running all the time. I need some background service which keeps running even after the server has returned requested data.
Servlets won't fulfill your requirements, therefore you should use WebSockets.
As per my understanding, you are trying to push data from the server, therefore you need to a push architecture instead of pull architecture (Servlets are based upon pull architecture).
Java has native support of WebSockets
You can find several tutorials on how to use WebSockets in a Java Web Application.
Here is a link to a basic WebSockets Tutorial.
Hope this helps
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 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.
Scenario: User logs in on the client software which forms a persistent bidirectional connection with the serverside entity (server) which would process user specified tasks. When the serverside entity, while processing user's task, encounters an error or requires further user input, it will notify the client software, and wait until the client decides what to do. The client software will take the new user specifiefd inputs and send this to the serverside. The serverside continue where it last stopped with the new user specified inputs. This feedback cycle will continue until it's finished processing. The progressively updated user inputs will all be stored on the serverside and accessible and modifiable from the client software. So if a client deletes a specific input, that change will be immediately reflected on the serverside. On the serverside, an extra interface is probably required to route different user's clients to available hardware nodes (cloud) to support concurrent multi-user tasks running on the serverside.
On the client side, I suspect using sockets to connect to the server...
Now for the server, I am a little lost because there seems to be many different Java servers like Jetty & Netty. I am also practicing caution in order to not try and reinvent any wheels here.
Is building a server the right approach? or Build a webservice that will complete a specific task on demand?
I am also not just looking for a one size fits all solution (wishful thinking probably) but open to any insights on my current situation.
Netty will provide a lot of what it sounds like you need for this, without making you reinvent a socket server. That said, I would make certain that you actually need bidirectional, real-time communication between the client and server. If you can rework the problem such that the client-server communications do not need to be real-time, then things like RESTful webservices become a possibility, and (in my experience) are much less complicated and error prone.
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.