I want to create Java Network servers which share one IP address. Something like the Piranha cluster:
Is there any solution similar to this?
P.S They have to work as a cluster. If one server is down the second one should handle the traffic.
Well the obvious solution would be to try to build your Java servers behind the Piranha layer; i.e. implement the application services on "real server 1", "real server 2", etcetera in Java
I'm pretty sure that you can't implement a Piranha-like solution in (pure) Java. The IP level load balancing is implemented in the network stack in the OS kernel (I think) of the "director". That rules out (pure) Java for two reasons:
It is impractical to put Java code inside the kernel.
To do it in user space in Java would entail using native code to read and write raw network packets. That is not possible in pure Java.
Besides, the chances are that you'd get better network throughput if the director layer was not implemented in Java, pure or otherwise.
Of course, there are other ways to do load balancing as well ...
Just create your standalone tcp/ip servers to listen on different ports (and ofcourse the IP address would be same as this is your requirement)
Related
I need to transfer data from one process to another.
I'm quite familiar with the subject when the two processes were originated from C code - not once I used files, signals and pipes in C-code to accomplish it, but never have I tried to do it between two processes where one was originated from Java code, and the other from C code.
Since all the above methods require the (Linux) native API, and the JVM is on the way, I have decided to use a socket to communicate between these two processes, and I have a couple of questions:
How common is it to use socket to communicate between two processes on the same machine?
Does the fact that there is no designated "Server" and "Client" can set any obstacles (implementation-wise)?
The reason I'm asking is that everywhere I read online, there is always one process defined as 'server', and one as 'client'. This is not the case in my situation. Plus, I never tried to use socket for this purpose.
How common is it to use socket to communicate between two processes on the same machine?
It's quite common for a certain class of interaction patterns: when two independently-launched programs need a bidirectional communication channel. You cannot easily use pipes for that ("independently-launched" interferes). You can use FIFOs, but you need two, someone needs to set them up, and there are other quirks.
Does the fact that there is no designated "Server" and "Client" can set any obstacles (implementation-wise)?
The distinction between "client" vs. "server" is first and foremost about roles in establishing communication: the server sets up the communication interface and waits for one or more clients to open a connection to it. Being a "server" does not necessarily imply supporting multiple clients (neither concurrently nor serially), nor does it necessarily imply anything about communication passing over the socket connection after it is established. If you use sockets then you do have client and server, but if you have no other way to designate which process should have which role then you can choose arbitrarily.
One trick with sockets in Java is that although the Java standard library supports them, it supports only network sockets, not UNIX-domain sockets. The latter are more commonly used in UNIX and Linux applications where communication is inherently restricted to processes running on the same machine, but network sockets listening to (only) the loopback interface can nevertheless serve that purpose, too.
On modern systems, local TCP connections are just as fast as UNIX-domain sockets, so using them is not a problem.
Connecting 2 processes together in a language and platform agnostic way can easily be achieved with a Socket. It's supported by all languages and platforms, and can easily be replaced with another method if wanted.
From your explanation I gathered that the Java process would be the server. Sockets are quite risk-free, since they don't require special permissions (for ports over 1024 at least) or any other special handling.
Just pay attention when designing the (application level) protocol your processes will be communicating through.
You might want to use the Java Native Interface. It might be exactly what you want. - Based on your aproach to use sockets on both programs.
You might want to look into shared memory on linux.
BUT: Using sockets is not a bad thing here in general, but i doubt it is common practice*.
*I lack proof, that this is not common practice tho.
I have to monitor the ports which are in use under the server (i.e. all the clients who are accessing the network) and especially it must be made in a such way that it should monitor based on the bandwidth utilized.
It should report the anonymous ports (the uncommon ports which are not for any specific application or protocol) which are being used beyond some threshold value (for example, 200KB or 2000KB). Can this be implemented easily?
I'd check out jNetPcap. I used this years ago to do something similar. How 'easy' it would be for you to use and implement the solution you're looking for is hard for me to answer.
Note, I believe it does require installation at one of the communication endpoints. If that doesn't suit you, maybe look into getting data directly from routers or other network hardware.
Can I create on Java monitoring program of network traffic? The program must control all network traffic which goes from computer program (including OS modules) to Network driver and back. If yes, How?
NOTE:
I want not only to monitor traffic also to control it. I want to implement such system on windows NT. It cannot be fulfilled o purely on Java. How can I perform it with the help of JNI?
Or maybe another variant. I am not acquaint with windows services, but still. I will write a program on C++ and register it as windows service. Then I call from my Java application this service (I don't know how to do this) and request network traffic. On the C++ program part all the traffic will be blocked if there is no Java program (or it doesn't request traffic); on the other way transmitted to this program. May be the java part can be implemented and work on an Java server (Glass Fish, JBoss). The C++ part in turn will transmit traffic to localhost.
What do you think about these ways?
When "monitoring of network traffic" then pcap, I'd say.
Googling "pcap java" brought me that as first hit: jNetPcap.
Did not test it, but pcap is the standard solution for native C programs. Cannot tell if the Java wrapper is good, but at least its website looks nice. ;-)
I'm thinking about writing a game which is based around a server, and several client programs connect to it. The game (very) basically consists of a list of items which a user can 'accept', which would remove it from the list on all connected computers (this needs to update very quickly).
I'm thinking about using a Java applet for the client since I would like this to be portable and run from a browser (mostly in Windows), as well as updating fast, and either a C++ or Java server running on Linux (currently just a home server, but possibly to go on a VPS).
A previous 'incarnation' of this game ran in a browser, and used PHP+mySQL for the backend, but this swamped the server quite a bit when several people connected (that was with about 8 people, this would eventually need to handle a lot more).
The users would probably all be in the same physical location (with the same public IP address), and the system would get several requests per second, all of which would require sending the list back to the clients.
Some computers may have firewall restrictions on them, so would you recommend using HTTP traffic, a custom port, or perhaps through SSH or some existing protocol?
Could anyone suggest some tips (threading, multiple requests of one item?), tools, databases (mySQL?), or APIs which would help me get started on this project? I would prefer C++ for the backend as it would be faster, but using Java would allow me to reuse code.
Thanks!
I wouldn't use C++ because of speed alone. It is highly unlikely that the difference in performance will make a real difference to your game. (Your network is likely to cloud any performance difference, unless you have 10 GigE between the client and server) I would use C++ or Java because you will get it working first using that language.
For anyone looking for a good networking API for c++ I always suggest Boost.Asio. It has the advantage of being platform independent, so you can compile a server for linux, windows etc. However, if you are not too familiar with c++ templates/boost the code can be a little overwhelming. Have a look, give it a try.
In terms of general advice. Given the description above, you seem to need a relatively simple server. I would suggest keeping it very basic, single threaded polling loop. Read a message from your connected clients (wait on multiple sockets), and respond appropriately. This eliminates any issue around multiple accesses to your list and other synchronization problems.
I might also suggest, before you re-write your initial incarnation. Try improving it, as you have stated:
and the system would get several requests per second, all of which would require sending the list back to the clients.
Given that each request removes an item from this list, why not just inform your uses which item is removed, rather than sending the entire list over the network time and time again? If this list is of any significant size, this minor change will result in a large improvement.
How can two/multiple JVMs running in a same machine communicate without RMI?.
Thx
If you are concerned about the security of JVM to JVM communication against snooping with Wireshark, etc, you could consider doing your RMI communication over an SSL secured channel, or the equivalent.
However, if someone is able to run Wireshark on the same machine as your two JVMs, this probably not be sufficient to solve your problems. And using an alternative to RMI is not going to make you more secure either.
For a start, if the bad guys have sufficient privilege to run Wireshark, they almost certainly have the privilege to interfere with the JVMs in ways that would subvert your use of a secured channel. For example, they could probably attach a debugger to the JVMs, or hack the application code (via the file system) to leak the information you are trying to protect.
In short, you would be better off just using RMI, and spending your time making sure that the bad guys cannot get into your machine to run Wireshark (etc) in the first place.
Communicate or invoke methods?
You could always open sockets and communicate directly via an arbitrary protocol, or even pass objects back and forth in serialized forms. On most operating systems, socket connections between processes on the same machine are faster and more efficient than connections between machines.
A good place to start would be to look at a JMS tutrial. JMS requires an extra broker process, but makes communication between JVMs a piece of cake.
There are also things like J2EE and even http based XML-RPC but these might be overkill for your needs.
sockets, remote EJB, web services ... from the top of my head. What is your specific case?