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.
Related
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?
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.
I want to create a voice chat application in pure java socket programming.
I used UDP protocol to transfer recorded voice from one client to another but when i test it over the internet voice is not comming continuously.
As i am new to this voice chat application, someone may suggest what should i do for getting continuous voice.
The Scenario is like this.
Flow of voice chat as this shows only one way communication-
FLOW of data
Client1------------------------------>> Server ------------------------------------>>Client2
Client1:
Reading 1KB voice buffer from TargateDataLine then create a voice packet and sent to server.
Server: Receive from client1 and then send to client2.
Client2: Receive the UDP packet and get voice data then play.
Also facing the bandwidth up and down problem.
What should be the minimum bandwidth to use voice chat. Ex- skype required 30KBPS udloading/downloading speed.
Thanks in advance.
In order to establish a connection between two or more users for peer-to-peer communication you need a signaling server as well as STUN/TURN servers.
You can code your own ones or use a ready backend solutions like ConnectyCube and concentrate on client-side implementation. Here are some WebRTC video chat code samples for your reference as well.
You should send the packets directly between the clients. The relaying of packets through the server is adding more delay to it. Simply send it from client1 to client2.
The Answer is pretty simple you should use tcp protocol. Coz udp sends the packet but doesn't ensure that the packet was received by the target. but tcp protocol ensures it and you will get a stable connection with cost of some speed reduced in transfer of data.tcp vs udp
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
Can a J2ME app be triggered by a message from a remote web server. I want to perform a task at the client mobile phone as soon as the J2ME app running on it receives this message.
I have read of HTTP connection, however what I understand about it is a client based protocol and the server will only reply to client requests.
Any idea if there is any protocol where the server can send a command to the client without client initiating any request?. How about Socket/Stream based(TCP) or UDP interfaces?.
If the mobile device doesnt allow you to make TCP connections, and you are limited to HTTP requests, then you're looking at implementing "long polling".
One POST a http request and the web-server will wait as long time as possible (before things time out) to answer. If something arrives while the connection is idling it can receive it directly, if something arrives between long-polling requests it is queued until a request comes in.
If you can make TCP connections, then just set up a connection and let it stay idle. I have icq and irc applications that essentially just sit there waiting for the server to send it something.
You should see PushRegistry feature where you can send out an SMS to a specific number have the application started when the phone receives that SMS and then make the required HTTP connection or whatever. However, the downside of it is that you might have to sign the application to have it working on devices and you also need an SMS aggregator like SMSLib or Kannel
You can open socket connection and implement "Hide" (or "Minimize") functionality in your app. Call this to hide:
Display.getDisplay(MyMIDlet.instance).setCurrent(null);
Listen to the server in a loop, and if you receive some message, popup the applicaion by calling this from canvas:
Display.getDisplay(MyMIDlet.instance).setCurrent(this);
But it dosen't work on all devices.
Socket push are supported by j2me. But it could work only if your server could deliver data to your mobile phone. Most likely that operator gateway don't allow to do this.
Maybe it would be possible if your mobile has static external IP address - some operators could provide this for $$.