Recently i developed a simple chat application in java using sockets. It was working fine. But now i want to make an application which can communicate over the Local Area Networks like IPMSG. The features will be
message sending.
file sending.
voice chat.
group chat.
encryption/decryption on demand.
These were the basic features to be included.
Now the confusion i am facing over here is
The application is an peer to peer application in which one user can do anything what other users can do.
There is no centralized server and there in no client. Every node acts as a server and client both.
So the application has to be peer to peer. But when i googled it then i am getting samples like client-server only and when i talk to my peers regarding this then also they suggest me the client-server model but there is no justification for why client-server and why not peer to peer. Am i right in this case ? Can anyone please guide me in this case because once i start development on any of these concept i cannot revert back due to time shortage. Your suggestions are most welcome.
I think the main reason a server-client relation is advised, is to make it easier for logging, or make a large chatroom for everyone (like IRC). If there is a login required, the server would also verify the login details. So without a server in between, phishing attacks would become more difficult to deal with.
I don't see why a P2P chat wouldn't work, though. If I recall correctly, Skype is doing that. I always love decentralizing. Good luck with your project. :)
You might want to check out the Zeroconf standard and packages that use it like Avahi (linux FOSS) or Bonjour (Apple & Windows open-source but not GPL). Zeroconf allows for configuration and detection of network services without user interaction or a central configuration server.
I end up using a client server model modified to support to P2P networking. When a node comes into the network it broadcasts its presence and the other nodes are continuously listening for new nodes. Each node will have their own list for the connected nodes in the network. In case of new node coming into the network they will update their own lists. I am using UDP for all most all the operations except file transfer as it needs to be in TCP.
Related
I am using mqtt and mosquito broker to build a simple instant chat for an android platform. Now I wanted to implement a condition where any client can check if another client is online.
I know about Last will and testament but I wanted a user to be detected offline only wen the application is inactive or the user is not currently using the app.
I actually dnt need any code, buh wanted an idea as to how to implement this and I would be much grateful.
You can do this without relying on MQTT internals which is much easier in my view. With this approach, you have much more control over what is going on:
The client can periodically send a message within another topic to inform the server of its availability. In case the server does not receive that message after a specified amount of time, it can assumed that it is offline.
The client can also send another message if the user logs out and inform the server a well.
If you insist on using MQTT internal structure, you may find this question useful:
How to Find Connected MQTT Client Details
I'm developing a Desktop LAN base java server and client application
where a Client must login and also to pass some data to server.
assuming i have 10 clients that inserting record simultaneously to server.
which is the best approach in this kind of situation, should I use RMI for login and record insertion? or Sockets?
if sockets please provide a key idea for me to start with.
key points to consider
-Multithreading
-able to send back data on client
If you want to connect your server via internet (and/or firewalls) it is probably a hassle to do this with plain RMI. In the past I have used Java Simon for such tasks which is very easy to implement. However if you plan to support other clients than Java clients, then you should have a look at Apache Thrift or Google Protocoll Buffers
I want to develop a simple push notification system for various android devices.
After two days of documentation i've found very interesting to use MQTT protocol.
System needs:
- an MQTT client on Android: eclipse Paho seems to be a good solution
- any MQTT broker you like for the server part: my attention is on Mosquitto cause is Open-Source
I've read documentation and the configuration file and seemed clear. The only thing that I couldn't understand is if i can manage topics (where clients subscribe to). In particular if i can create topics and how to.
Thanks.
It's not clear whether you mean on the client side or the broker side...
Assuming you mean the broker side, you don't need to create topics, they are created automatically as needed. You can control what clients have access to what topics using the built in authentication and ACL code, or you could use an authentication and access plugin. Writing your own is quite easy, or you could use the excellent https://github.com/jpmens/mosquitto-auth-plug
On the client side, simply subscribing or publishing to a topic is sufficient to create it on the broker, assuming you have permissions for that topic. This may not be the case in all MQTT implementations.
As an example, try subscribing to the # topic on test.mosquitto.org or iot.eclipse.org. These show a huge range of available topics and there is no admin to support them in the background.
This basically means that the only administrative load you have is restricting access on the broker where required.
Using code stole from somewhere, I made a pretty simple "MQTTMessenger" app for Android. https://bitbucket.org/mjgasner/mqttmessenger
From what I remember, you'll need to go into src/com/gasner/mqttmessenger/MessengerService.java
and change the host ip to the ip of your MQTT server.
For the MQTT server, I used Mossquitto server.
You'll also have to make sure you port forward port 1883 to the server.
I used this to send stock numbers to my phone. It's been almost 2 years ago, otherwise I could tell you more.
The C2DM directory is unrelated. It is Google's push notification service that I was also playing with at the time.
In the other directories at Bitbucket https://bitbucket.org/mjgasner are the .NET service and winforms app I wrote to communicate with the MQTT server. The service would accept the message from the android app through the server and reply with the stock amount it pulled from google's api.
If you have any more questions, comment below.
I am trying to learn how to make a multiple-client chatting program. Im following the Oracle tutorial on Custom Networking, but its not really what I am looking for. So far, I have no code of my own to share, all of it is copied from the Oracle tutorial and I think pasting it here would be a copyright infringement(??).
link at: http://docs.oracle.com/javase/tutorial/networking/sockets/clientServer.html+
client code link: http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/networking/sockets/examples/KnockKnockClient.java
anyway, I have the server-client working where the server tells knock knock jokes, the client reads and prints, then the user replies and so on. how would i start to edit it to have the client talk to the other clients directly?
im sorry, i have no background with networking at all. if anyone can direct me to a informative source better suited to my goals i would appreciate it.
as in the Knock-Knock example, each client connects to the server, but they not mutually directly connected.
There is a solution to make a forwarding sever :Arrange each client an id, and clients use id to identify their talking partners.
To do this, you have to modify the client to server data format from a plain string to a tuple like (String,Id). And, when the server receive the data, it parses out the id, get the corresponding client socket and then write the data.
The required level of complexity just went up a notch as your going to need some sort of "interprocess communications" infrastructure to allow client to client communication (possibly via sockets marshalled by the server?)
I am looking for solutions for a problem that we are facing. We are planning to make a POC for Desktop Alert application. We will have a desktop AIR app that will connect to a Java Server. The server will need to notify Desktop App when it has a notification which will be displayed on the screen.
A couple of options that we have discovered are :
1. Keep a persistent connection between the AIR app and the Server, using some sockets and listen to any changes.
2. Poll the Server at intervals to check if some new data has come.
Since these options don't seem optimal (persistent connection) or seems performance wise (polling) better.
Is there a better solution for this problem or do we have to choose one of these?
For this, you could use a BlazeDS message service if you want to push messages to your client. Or a regular remote service with polling enabled.
It is built in out of the box and well tested equipment :)
Other technologies like GraniteDS or WebOrb for java are also possibilities.
Cheers