I am interested in putting a chatting functionality as part of an application.
What I am interested in:
I would like to keep my application instances acting as peers, i.e.
I would prefer not to write also some server module to handle
message communications
I would like it to be able to use it with exising IM accounts. E.g.
someone can use it using his MSN account or any other client
account he may have, same way he would use MSN Messenger or Tor client etc
I googled and found that there are some Java MSN libraries available and also some other libraries that support IM e.g. SMACK for JABBER etc (not sure what that is) but I am not sure if the latter could be used for option 2 I mention.
My preference on 2 is because I assume that this way a user could do chat no matter where he is while in other solution I assume that some network infrastructure e.g. with routable IPs etc would be required. Am I wrong here?
Does anyone have expererience with Java IM libraries? Are for example any issues e.g. with different MSN versions or something?(Don't know if the protocol has been changing often to matter for me).
What would be the best path/option for my requirements?
I would go with a Jabber based approach. Jabber (also called XMPP) is an open protocol with lots of implementations and supports connecting to other IM services via transports. That way you would not have to deal with changes to the Windows Live protocols. You can rely on the open source community to provide that functionality for you.
Edit: It seems, that Windows Live even allows native XMPP access.
If you like, you can always set up your own Jabber server to provide a tighter integration with existing user accounts. In that case you wouldn't need to write the whole server.
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'm building a chat application that allows people from any website to communicate with my website. Here's the visual breakdown:
Website A Server Website B
Msg1 -------> Msg1 -------> Msg1
|
Msg2 <------- Msg2 <------- Msg2
Right now I'm using a polling solution that works for the time being, but it won't scale.
I'm wondering what solid solutions there are that I could use to facilitate this messaging functionality. I looked at JMS briefly, but it looked like it was only for communication from one Java server to another (not HTML to Java to HTML which is what my setup requires)
I wrote blog about how to implement Java WebSocket on Glassfish 3.1.2.2 but It's is Thai language. .... But I thought you can guess from code.
Anyway If you have any problem. You can ask me.
The most easy way would be to set up a database on the server (SQL/ MySQL) and then let the websites communicate with this server. (so this kind of leaves the Java server out of the question)
This is a nice stack question about that.
How you could build it is for example:
- server passes chat-id to both clients after identification
- clients recognise id and store id
- clients keep calling for the database through AJAX calls
- depending on how the database is designed, it could then update the client's chat
screens whenever a new row has been added to the specified database table.
Be careful for SQL-injection though. You don't want people to be able to read all conversations.
Apart from building your own solution, I can highly recommend going with one of the existing plugins.
For example this list of 10 free Website Chat Widgets is pretty good, but there is most definitely already something (open source) out there that fits your needs.
For example this plugin and this plugin looks nice if you want server side regulation. (Haven't used it myself though)
Or if you just want the 'framework' (as far as I may call it a framework), you can use the very low-end solutions like Blueimp's AJAX Chat.
Good luck!
I am currently trying to transfer a file from a Android device to a Java TCP Server, but I am unable to find a good example which explains the structure I would need to implement this. There are many Java Client&Server examples there which explain file transfer but I want to make sure if this will still work once one throws an Android Device in there.
My question is how do I implement this sort of structure? And if it doesn't work, would I be better sending the file over an HTTP connection to a PHP server? I see a lot of examples and documentation online for the later method so I presume it is more reliable. I would however prefer to use a Java server.
The file consists of a large set of coordinates recorded by the Android device which will then be sent to the server. I have not yet established how I will store this data yet but I was originally going to store them in a primitive text file.
Design
The first thing you need is something to allow you to run Java code on your server.
There are a number of options. Two of the most popular technologies are Glassfish and Apache Tomcat.
Crudely speaking Apache Tomcat is sufficient for simple client-server communication and Glassfish is used if you need to do more complex stuff. Both allow Servlets (which are essentially self contained server classes written in Java) to run on the server-side.
They handle communication with the client by launching a JVM (Java Virtual Machine) each time they receive a request. The Java servlet can run inside the JVM and respond do some processing if required before sending a response back to the client.Each new request is run in a new instance of a servlet. This makes dealing with multiple concurrent requests simpler (no need for more complex threading).
Networking (sending data to and from the server)
In networking situations the client can be a PC, an Android phone, or any other device capable of connecting to the internet. As far as the server is concerned, if the client can communicate using HTTP (a standard protocol which it understands) the it doesn't care what sort of device it is. This means that solutions for PC desktop client-server applications are similar to one for a phone.
You can use library such as Apache HTTP Components to make it easier to handle HTTP requests and responses between the device and the server. Of course you could write your own classes to do this using Sockets but this would be very time consuming, particularly if you have never done it before.
Storage of Data
If you have time I would recommend implementing some sort of database to store the information.
They have a number of benefits to such as data recovery mechanisms, indexing for fast searching of data, ensure data integrity, better structuring of data and so on.
If you decide to use a database I recommend MySQL. It is a free and more importantly - well documented.
Aside: JDBC can be used to communicate with the database with Java.
Sorry about the in-line hyperlinks - apparently my repuation isn't high enough to post more than two!
Source: Personal experience from implementing a similar design.
I'm looking for a library that will allow me to deliver simple text events from the server to the clients via sockets. Something simple and lightweight. I can write it myself, but decided to check if such thing exists first. The idea is that there's an application that generates events (such as order rejected or an internal error occurred) and acts as a server. Those events must be delivered to all connected clients in real-time. And a client is just a tray-icon app that pop ups the said event's text. Some simple UDP client/server. Does anyone know if there's a library out there for Java?
Thanks!
There are many possible solutions, but if you want simple I suggest you try Hazelcast
It is as simple as using java.util.{Queue, Set, List, Map}. Just add the hazelcast.jar into your classpath and start coding.
This could be easily accomplished with XMPP pubsub. You can use Smack to connect to the server of your choice that supports pubsub (OpenFire, ejabberd, ...) so your application that creates the events is the publisher and the clients are all subscribers. It will require a 3rd party server to be used (many are open source), but it is just a single library for all client access. I have experience with OpenFire and it can be set up in about 15 minutes.
Many will not consider this light weight, but rolling your own pubsub solution is really not necessary.
You should check out JBoss Netty and/or Apache MINA, which are both frameworks for building network protocols. It's debatable whether you consider them simple, although you can certainly build lightweight implementations with them.
I'm currently working on a project that is building a java-based desktop application to interface with a website. We want to incorporate IM capabilities, so we decided to use XMPP.
The problem is our application has other features, and anyone using another client to connect to our XMPP server will cause problems with our website (e.g. our client will be able to send our messages with a certain message type that the user won't be able to use, but with another client they could send those message types).
Is there anyone to either allow only our client to access the XMPP server or prevent other clients from using certain features? I know this is against the idea of open standards, but we don't want to build a proprietary IM solution from scratch.
You are building a proprietary solution, it just might not be completely from scratch, and that's not necessarily a bad thing. But please don't call it a XMPP service unless you are going to support XMPP clients. You will get the same reaction as you get with a "web site" that requires your proprietary browser.
For features that can be negotiated, look at Feature Negotiation and you might be able to get away with saying your server doesn't have a specific feature to other clients, but secretly supporting it in your own. That won't actually block something from being attempted, so it's pretty poor solution.
You can get instant messaging capabilities without building a desktop application (with all of the platform support headaches that entails). Consider Orbited which can give you the instant messaging interactivity your looking for and would make it much easier to integrate on the server.
And just as a side point, there shouldn't be any messages that cause problems with your web site, any more than there could be a URL that causes it problems, or a query combination, etc.
Not sure of all your requirements, but it sounds like you could probably use the pubsub or pep features of XMPP. These are extensions to XMPP that allow you to create specialized payloads that can be accessed on a user to user level (Personal Eventing Protocol XEP-0163). If it is simply a general notification to everyone who is interested, then PubSub (XEP-0060) may be what you want.
These protocols allow for securing access to the pubsub nodes and will not get affected by the standard chat messages, as they are a different protocol.