SSDP Device Discovery for Application in Java - java

I have some hardware devices connected to a specific network and I have a Java application also running in the same network. I now need to detect these devices from my Java application. The specification is like this:
My Java program has to send a UDP packet with a host name
{"type":"HW-PROBER","hostname":"Host-NAME"}
The hardware upon receipt of this message sends me back a response with the NOTIFICATION in the form of a Payload that looks like this:
{"type":"HW-NOTIFY","hostname":"Host-NAME","ip":"1.2.3.4"}
So this way, my Java application has to get the ip address of the hardware and start communicating with it. I'm totally unclear on how to do the device discovery. Would this mean that my Java application has to open a port say at 5000 (for example.,) and keep waiting for packets? What sort of API from the Java standard library should I be using?

Related

Need suggestions for reliable data broadcasting inside LAN using Java or android

We are working on a Android project with the below requirements.
The application should be able to send data to all the devices which are running our application which exists in the WiFi LAN.
Some payloads are expected to be of size >= 5MB.
The data shouldn't be lost and if lost the client should know the failure.
All the devices should be able to communicate with all other. There will be no message targeted to a specific device instead all the messages should be reached all the devices in the N/W.
No internet hence no remote server.
Study we have done:-
UDP Broadcasting - UDP doesn't guarantee the message delivery but this is a prime requirement in our case. Hence not an option.
TCP - TCP guarantees the message delivery but requires the receiver IP address to be known before hand and in our case we need to send the message to all the devices inside the LAN. Hence not a straight option.
Solutions we are looking into:-
A Hybrid approach - Name one of the devices in the N/W as Server. Post all the messages to a local Server. The Server keeps a open socket to all the devices(which have our application) & when there is a message from a device then it routes the message to all the devices. The disadvantages of this approach are,
Server having multiple sockets open each per device. But in our case we are expecting devices <=5 in LAN.
Server discovery using continuous UDP broadcast.
We want to have all the data in all the devices. So if we newly introduce any device into the LAN then that device needs to get all the data from the server.
So my question, have you any time worked on these kind of hybrid approaches? Or can you suggest any other approaches?
Your hybrid approach is the way to go.
Cleanly split your problem into parts and solve them independently:
Discovery: Devices need to be able to discover the server, if there is any.
Select server: Decide which of your devices assumes the server role.
Server implementation: The server distributes all data to all devices and sends notifications as necessary. Push or pull with notifications does not matter.
Client implementation: Clients only talk to the server. The device which contains the server should also contain a normal client, potentially passing data to the server directly, but using the same abstract protocol.
You could use mDNS (aka Bonjour or zeroconf) for the discovery, but I would not even recommend that. It often createsmore problems than it solves, and it does not solve your 'I need one server' problem. I would suggest you handcraft a simple UDP broadcast protocol for the discovery, which already tells you who the server is, if there is any.
Select server: One approach is to use network meta data which you have anyway, for example 'use the device with the highest IP address'. This often works better than fancy arbitration algorithms. Once you established a server new devices would use this, rather than switching the server role.
Use UDP broadcast for the discovery, with manual heuristic repeats. No fancy logic, just make your protocol resilient against repeated packets and repeat your packets. (Your WLAN router may repeat your packets without your knowledge anyway.)
You may want to use two TCP connections per client, potentially to two different server ports, but that does not matter much: One control connection (always very responsive, no big amounts of data, just a few hundred bytes per message) and one data connection (for the bulk of the data, your > 5 MB chunks). This is so that everything stays responsive.

Receive UDP Packets on Google Compute Engine

my task is to receive UDP packets on an Google Compute Engine. Given is the port, which is 300 and I already have a simple Java program which can handle these UDP packets.
My problem now. Get the UDP packets to my Java program.
For that I don't know how to do this.
What I have tried so far ist to let the Java program direct listen to the port, which didn't work. I suspect the traffic from outside the GCE must be routed to the inside?
First make sure you've added a firewall rule on your GCE VM instance's network which allows incoming traffic for UDP protocol on port 300.
You can do this by going to the Developers Console, select your project, then Compute-> Compute Engine-> Networks, click on the right network and verify firewall rules (and tags as well if you used them). If the rule is not added, then add a rule for the traffic.
"gcloud" is a command-line tool which you can use it to list and verify your firewall rules as well [1]:
$ gcloud compute firewall-rules list
If the firewall rules are good, then use a simple troubleshooting tool like netcat to test if traffic is being forwarded to your VM instance.
1. Listing Google Compute Engine firewall rules
I recommend not using Java to process UDP. I experienced inexplicable short periods where all UDP traffic arriving was being lost. This was caused by garbage collection.
The architecture that works for me is to use a GCE VM with a C++ app receiving UDP data, then using libCURL, convert the data to HTTP and dispatch it to Google App Engine for processing. To make the UDP receiver scalable and tolerant, use network balancing and multiple VMs listening for UDP.

Sending data at the same time as connecting using sockets in java

Using sockets in java, is it possible to send information at the same time as connecting?
For example I want a remote device to control another device (such as a virtual appliance) using 'Client Server'. So the remote will switch the appliance on. When I connect to the Server I would like to allow the server to be able to determine what type of device it is, either a remote or appliance without sending a messages after connecting.
Is this possible? Or would there be a better way to implement this?
Thanks
You could set up different ports on the server, and have different kinds of devices connect to different ports. That way, the port number of the incoming connection would identify the device before the first byte of payload data has been transferred.

Find an application running on a network

I'm new to networking and was wondering a way to find out from an android phone java app whether there is an application running on any computer on a wifi network it's connected to and a point in the right direction on what to google or a tutorial?
edit: The application I'd be finding would have been made to be found by the android app
Thanks,
Harold
You should use a UDP broadcast. Basically, a server announces its presence periodically on a local network with broadcast packets. A client then picks up on these packets, finds the source and connects to it. A networking library like KryoNet (available for both J2SE and Android Java) makes it much easier.
InetAddress address = client.discoverHost(54777, 5000);
System.out.println(address);
usually application discover their peers in the same network using UDP broadcasts, maybe thats what you are looking for. this requires the app on the lan to listen on a specified port, the phone (or whoever is looking for that app) sends a udp packet to that port on the broadcast address (255.255.255.255), and the app replies with its individual ip address. not sure if that is what you are looking for and if its possible with android

How should I go about implementing this SMS notification system?

I have developed a application which involves billing users. To do this i have incorporated a GSM modem (gateway) that the SMS messages are sent through. This SMS message is sent to the user when he is billed with the bill details. The GSM modem is connected to a single computer but the billing can happen in other systems. How do I send an SMS notification for the changes that occur in the other systems, as the GSM modem is attached to a COM port on the computer*.
can we access the COM port of other system or shoould i use socket programming (with the machine with the modem(Server) listening for any connection, the sender has to send data in particular format and the server has to parse the data and send the message) or use Java RMI or is there any other solution.
Suggestions please....
Thank you
There are any number of solutions you can think up. The most common ones would be:
Communication with some kind of RPC, be it RMI, SOAP, plain HTTP, telnet, etc.
Using an SMS gateway such as Nordic Messaging’s EMG (probably overkill, though) or kannel (seems to be down currently).
We've got an SMS Gatway. We wrapped it in a J2EE-application with a webservice interface. That way we can send SMS from any of our applications. For the sake of java we made a little jar-file that talks to the webservice
SmsClient smsclient = new SmsClient();
smsclient.sendSms(from, to, message);
I built a similar system to this in the past where small embedded systems sat on a network and reported messages over the network to a central server that logged the messages and sent SMS messages when required.
I used a java socket listener that waited for UDP messages from the embedded units and the java program wrote to the GSM modem on the servers comm port. UDP was only used instead of TCP as it was simpler to configure on an embedded system.

Categories