I need to connect to a hardware device which is in LAN, and we need to ping that device through some hex code and the device is sending some response to the ping command. How do I read that response?
You are going to need to look up networking code, specifically, sockets. Although it takes a bit of extra learning, sockets are best handle using a few threads, unless you are willing to have your application wait for the response.
I would give more info, but I doubt you will even notice this, if you do I can add some more info for you.
Related
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.
I'd like to implement a function of realtime message such as chatting in facebook but several questions confuse me:
1. To reduce overhead of server and make it really 'realtime', I should use a full-duplex way of communication like socket instead of Ajax, is that right?
2. If I use socket, which protocol should I choose, TCP or UDP?
3. Assuming that I am using TCP, will server keep trying to resend the lost packages so that it would take much overhead?
4. What if the network failed in a communication between server and a client? Will the socket close it self or I should handle with several kinds of network conditions?
Can anyone help?
You can use WebSockets. XMLHttpRequest is probably obsolete now for anything real-time (because it's not real-time), though you could fall back to using it for people who use a browser that doesn't support WebSockets
Use UDP if the information you are sending is only valid for the time it is sent, for example in games that would be the position of the players (you don't care to receive the position they were in 5 seconds ago). Besides, you can't use UDP with WebSockets
For anything other than that, use TCP (unless you do hole punching to achieve p2p), because loss of data is probably bad for you, and TCP handles that.
You would have to check for and resend lost data manually with UDP anyway, unless failure in communication is acceptable by you
You will get an IOException. If the connection was closed improperly the exception will be thrown after a timeout of unresponsiveness that you are able to change according to your needs. This is assuming you use TCP, otherwise you should figure out yourself when you consider clients connected or disconnected according to the responses/data you receive (or not receive).
Is it possible to make my local computer function as a gateway in Java? I need the other local machines to connect directly to my computer to see if they are alive or not.
You could run a Java server program on your desired PC and let it listen on a port. Then you could use other programs (browser, other Java programs etc.) to connect to this port, and send commands to be executed by the Java server program.
If you just want to see if the PC is turned on or not, I'd just use the ping command though. Or see this answer: How to do a true Java ping from Windows?
Surely it's the other way round? Surely you want to connect to the other machines to see if they're alive? In which case see InetAddress.isReachable().
Try this.
Create a Java Server Socket, which keeps listening to the client at some port.
Write a client in Java which connects to the Server, wrap the connection logic in try-catch block....
If your host is alive the try code is executed which contains the code to connect to the
Server, if this connection process fails you will get UnknownHostException, here you can instead type a message that the connection failed.
You could more easily manage and control this by polling for other devices from a central server. If possible, avoid unnecessary client/agent apps that might tax your development and support resources as well as taking up RAM on the client workstations.
There are many monitoring tools that already do what you want. I'd have a look at Nagios, for example.
If you want to develop your own app, do your own quick troubleshooting, or just get a feel for network discovery tools, then take a look at NMAP. You could, for example, search a subnet for anything that responds to TCP:445 and see what Windows machines are alive.
If you do go the Nmap route, please have a look at Nmap4j on Sourceforge. It's a Java wrapper API that simplifies the work needed to integrate Java and Nmap.
Cheers!
given a flash application that opens a socket connection to a webserver, is it possible to reads packets exchanged with a java application, without redirect all the flash traffic ( that is, without programming a socket proxy)?
What you are trying to do requires lower level network analysis than sockets. Namely libpcap and its Java bindings , jNetPcap. This will let you capture packets much in the same way wireshark does, but from Java. The other options are analysing Wireshark logs after an experiment and that can get clunky quite quickly. You may also consider writing a custom wireshark dissector.
The only way I can think is to modify the hosts file to list your Java server address as if it was the destination address.
BTW if your are only interested in examine the network traffic for that app, you could also use fiddler
I'm new to Java and RMI, but I'm trying to write my app in such a way that there are many clients connecting to a single server. So far, so good....
But when I close the server (simulating a crash or communication issue) my clients remain unaware until I make my next call to the server. It is a requirement that my clients continue to work without the server in an 'offline mode' and the sooner I know that I'm offline the better the user-experience will be.
Is there an active connection that remains open that the client can detect a problem with or something similar - or will I simply have to wait until the next call fails? I figured I could have a 'health-check' ping the server but it seemed like it might not be the best approach.
Thanks for any help
actually i'm just trying to learn more about RMI and CORBA but i'm not that far as you are. all i know is that those systems are also built to be less expensive, and as far as i know an active conneciton is an expensive thing.
i would suggest you use a multicast address to which your server sends somehow "i'm still here" but without using TCP connections, UDP should be enough for that purpose and more efficient.
I looked into this a bit when I was writing an RMI app (uni assignment) but I didn't come across any inbuilt functionality for testing whether a remote system is alive. I would just use a UDP heartbeat mechanism for this.
(Untested). Having a separate RMI call repeatedly into the server, which just does a "wait X seconds" and then return, should be told that the execution has failed when the server is brought down.