This question is more concerned with the general design of a program. I have a problem in hand in which a centre communicates with a set of clients individually (the clients do not directly interact with each other).
The content of the communication between the centre and a client is entirely numeric, i.e. a bunch of numbers are sent back and forth. The clients are run on individual computers, and the centre can be hosted on another machine (or otherwise). The style of communication is iterative and synchronous in a sense that the centre sends a request/question msg to each individual client and the user of a client provides an answer/reply back to the centre within a time limit in each iteration, and this interaction repeats itself for a number of times until the end.
The centre does some calculation given the responses received from the clients, and the clients simply provide the inputs to that calculation.
I wonder what is an elegant design for this problem using Java? Any comment or suggestion is much appreciated. Many thanks.
I'd use KryoNet which can efficiently serialise your datasets over RMI invocations (remote method calls). Using it myself, and it works well. Has UDP and TCP without any mucking about. Start from the example on the site and work from there. You can easily get both sides of the connection working with RMI.
Sounds the MPI is right for you. Here is a Java version.
Good luck and Regards.
The simplest solution in pure Java is probably to use RMI. Just expose an object via RMI and have the clients call methods on it remotely.
If you want asynchronous behavior, you can use a JMS implementation or roll you own using sockets and TCP/IP as mentioned above.
If you don't like any of those, the MPI mentioned above may be for you. Or possibly Apache Hadoop may be for you.
Related
sorry if my english isn't perfect.
I'm trying to make an app and I need to exchange information between more devices.
I thought that could be a solution connect the devices on a server but I really don't have the idea where start.
What language I need to study to make this? There is a better solution?
This highly depends on what you are trying to achieve in the first place. It would be helpful if you could tell what you are trying to do, but I will still outline some general aspects:
You need to decide, what information is going to be exchanged and how this should happen
What information: Figure out, what exactly needs to be sent and received. Generic text messages? Images? Byte Streams?
How should this be done: Generally spoken, there are two approaches of getting information as a client: Polling and subscribing.
Polling: This approach means to periodically check an endpoint for new data. For example, HTTP uses this way: A web browser or any other client (REST-Client for example) periodically requests information from a HTTP-Server, using a connection just for this single request.
Subscribing / Sync / Notification: In some way or another, the client tells the server that it is interested in the information and wants to get notified when there is something new. The connection is initiated at the beginning and held open for further usage. The benefit of this approach is that changes are received immediately, but on the other hand a permanent connection needs to be maintained.
Things to study
At the beginning, get a good understanding of the TCP/IP Protocol, how Sockets work, how common Protocols do their job (e.g. HTTP, WebSockets)
Take a look at specific Protocols working on top of the basic ones
Tip: REST: Most common WebServices Protocol, providing a common way to exchange stateless data. Uses Polling.
WebSockets: Socket connection using Web Browsers. Commonly used to update information without needing to poll.
There is no specific language to learn for connections. It's more about understanding what the difficulties are and what ways have been invented to address this. Once you get to this point and know what you want to do, it's possible in every language.
Recommendation: As you seem to use Java/Android, I would try to use REST. A really great client-side library for REST on Android is Retrofit. For the server side use what fits for you .. common Java way would be to use Jersey, but you are free to choose from a lot of choices. If using Jersey is too hard for the beginning, maybe take a look at the JS/NodeJS world, those guys invented Express, which allows you to create a REST service out of just a database, wihtout having to code a lot.
First you need to decide if you want to go for an Android or an iOS application. There are other various mobile operating systems as well, but these are widely used . If you want to go for android which is most widely used in my opinion, then you need to learn Java. If you want to go for iOS application, then you need to learn swift or objectiveC. These languages provide the API to connect with various types of services such as Facebook, Firebase and Amazon etc. If you want to connect to some other local server who’s IP is known to you, then you can use socket programming to send messages.
There could be many ways you can implement this. One way will be using Web services. Of course REST might be a better option, if you follow this approach. You can implement Your service(server side code) with any language. I will recommend you use java since you are already using android.
Aside from this You might need to go through the basics of REST, its specifications and
some reference implementations for language of your preference.
I'm developing a distributed application, and I need to connect a client Java based to a server C++ based. Both of them will need to send information to each other, but I need them to be able to do things while waiting for the information, and they don't know when they are gonna get new information, or send information.
How can I achieve this? Now I'm trying to implement a basic communication with Sockets, but I don't really get to communicate them. I have read that using sockets + threads is usually a good approach for client-server apps.
Could you please recommend me some web or book to read about this, or send me some example code to learn?
Do you think that i should use other approach, better than sockets? maybe a higher level library (i would need it for c++ and java) or a totally different way?
EDIT:
I will add some extra information.
What I would love to achieve is the following:
My C++ program has a main loop, where I would like to have a call like GetUpdatedDataFromRemoteDevice() where I read the new values of some numerical variables that previously got updated from the net (the socket, for example).
Eventually, the C++ program will need to send a message to the remote device, to tell him to send other kind of data, and after that, keep getting the updated values.
From the Java program (remote device) the application running is an interactive touchable screen, that cant get blocked by the network transmissions, because it must keep working for the user, so all the networking should be done in a separated thread.
That thread, should connect to the server, and when a button is pushed, start to send the data (4 changing numerical values) in a loop until another event happens.
It would be nice also to be easily re-connectable to the server.
ICE is a modern and good library for distributed applications:
many languages as C++ and Java
many platforms
GNU GPL
good performance
easy to use
First, you define the messages you want to exchange between server and client.
Then, you implement the C++ and Java source code to handle these messages.
More info at http://zeroc.com/ice.html
Have fun ;-)
EDIT: I have to use ACE in some projects. I can tell ACE is very old, maybe mature, but uses outdated C++ coding rules :-(
Therefore ACE is not as easy to use as STL or BOOST. Moreover, ACE is not really efficient... I prefer ICE ;-)
I don't know what your application is but robust client server socket programming is pretty hairy task to do properly. Hardware byte order, String encoding, Network errors, retries, duplicate messages, acks etc.. require lots of good design and careful programming. You need to get it work well as single-threaded before even thinking using multiple threads.
Unless you need instant notifications from server to client I suggest that you use HTTP as protocol between client and server. Client can poll server occasionally for new messages.
Anyway the problem has been solved multiple times already.
http://activemq.apache.org/
http://www.rabbitmq.com/devtools.html
http://www.cs.wustl.edu/~schmidt/ACE-overview.html
I did something of this sort once. In my case it was easier to connect my C++ app to a local Java app using JNI and then have the two Java apps talk to each other.
I'm currently considering using java in one of my projects(for reasons unrelated to networking). At the moment I'm using C++ and a custom protocol built on top of UDP. My problem here is that while the added efficiency is nice for sending large amounts of realtime-data, I'd rather have something along the lines of RPCs for pure "logic actions" such as login. RPC's in C++ are hard to do though, since standard C++ itself has no notion of serialization.
In another answer, I found Java's RMI, which seems to be similar to RPCs, but I couldn't find how efficient/responsive it is, nor whether it could be plugged into my existing UDP socket, since I don't want to have two ports open on my server program.
Alternatively, since I think Java has serialization, I could implement RPC's myself, depending on how straightforward deserializing an arbitrary stream of objects in java is. Still, if this would require me to spend days on learning the intrinsics of java, this wouldn't be an option for me.
If you're interested in RPC, there is always XML-RPC and JSON-RPC, both of which have free/open-source C++ implementations. Unfortunately, most of my development has been in Java, so I can't speak to how usable or effective they are, but it might be something to look into since it sounds like you have already done some work in C++ and are comfortable with it. They also have Java implementations, so you might even be able to support both Java and C++ applications with XML-RPC or JSON-RPC, if you want to go down that route.
The only downside is that it looks like most of these use HTTP connections. One of the things you wanted to do was to reuse the existing connection. Now, I haven't looked at all of the implementations, but the two that I looked at might not meet that requirement. Worst case is that perhaps you can get some ideas. Best case if that there might be another implementation out there somewhere that does what you need and you now have a starting point to find it.
The use of RPCs as an abstraction do not preclude the use of UDP as the transport layer: RMI is an RPC abstraction that generally used TCP under the hood (last time I looked).
I'd suggest just coding up a Java layer to talk your UDP protocol: you can use any one of many libraries to do it and you don't have to discard all your existing work. If you want to wrap an RPC layer around your protocol no reason why you can't do that: create a login method that sends the login UDP packet and receives the appropriate response and returns it.
If it's a remotely serious project, you should probably take a look at Netty.
It's a great library for developing networked systems, has a lot of proven production usage and is well suited for things like TCP or UDP client-server communication. I wouldn't go reinventing this wheel unless you really have to :-)
As a bonus they have some good examples and documentation too.
I'm building a multiplayer card game using Flex on the client side and Java on the server side and I wanted to know if I must sockets and the accept method in order to connect users to the server for in order for them to join a game room or create one or to chat.
In the past I've learned how to build a game server which both sides are JAVA and connection was in sockets but now days the client side will be in FLEX which has few ways to connect to a Java server (XML,SOAP,BLAZEDS(AMF)) and I find it hard to understand how to write the Java server in order to do all the features of a game server , especially managing the rooms and sending data back to the users.
In the sockets way, when a user was connecting to the server and he had opened a room, this room was opened on a thread and who ever was joined that room then he was connected to the same thread and sending the messages to the right place was easy, so the problem is understanding how to do the same using SOAP or BLAZEDS.
Any help would be appreciated.
Thanks.
Please make your questions concise, it is difficult to know what is being asked for.
If you ask the difference between socket and webservice, sockets are used to manage the basic networking communications. Over them, you can receive/send bytes in whatever format / protocol you chose to.
SOAP / Webservices is just one of such formats, its advantage is that it is a standard way of encoding messages so you can easily write code that connects to your service in most platforms, and those messages are human-readable. The main disavantage is performance, both in bandwith and processing power (specially to parse it at the receiving end).
If you are starting, I would advise designing a format related to the application you are using to simplify things.
Take a look at RED5 and remoteSharedObjects. Using this tech, you can essentially put you "game" object in a remote shared object, and all the clients will have the same object with real time updates. Then on top of that you can use AMF (the protocol behind BlazeDS) for your less dynamic data.
Using raw sockets gives you the benefit of control. Control of your protocol format ( how your message data is structured). And because of this you can tweak your messaging to be more secure, or faster, or more robust, depending on your application requirements. All that control comes at the cost of complexity and maintenance. Because you get to say exactly what you want to send and how you want to send it you need to write and debug alot more code. Another issue with raw socket communication is that it has a significantly greater chance of being blocked by firewalls.
Using web services removes some of the complexity of deciding on a message format (with that being it's main benefit). You don't have to worry about things like byte endian-ness, string encodings, or data conversions (as much). As such web services really excel at data communications amongst heterogeneous clients and servers where inter-operability is key. The cost being that it's relatively complicated to serialize/deseserialize, and as such, slower than binary messaging formats. Web services are good to use when you have to communicate with client applications that you have little control of (not really your case). Web services are traditionally tunneled through HTTP, so there is an additional advantage in being able to worry less about a firewall blocking access to your game.
BlazeDS attempts to bridge both worlds - it gives you some of the robust features of web services (fallback communication options, firewall interoperability etc), but uses it's own binary format for serialization/ deserialization. This gives it some of the speed of using raw sockets without a lot of the downsides. I think it's a great candidate to explore, but if you find yourself needing more speed then raw sockets would be worth messing around with.
Good luck.
Sockets are the programmatic interface to OSI Level 4 Transport Layer. Everybody uses them, ie Webservices is a Level 7 Application Layer interface that hides the lower levels.
If you need real-time bidirectional data exchange between your client and server you're better off managing your own TCP sockets. Flex still supports sockets.
Can any one suggest me a packet blocking software ??
My requirement is to block packets within the LAN.(Internet does not come into picture).
Supposing CLIENT_A communicating to CLIENT_B in the same network(LAN).
I want a CLIENT_C (who is in the same network) to capture(I can use jpcap library's sniffer for this purpose) and block packets sent by CLIENT_A to CLIENT_B.
How do i block packets over LAN..?
Thank you in advance.
Regards,
Veenit Shah
This kind of thing is normally done using a separate firewall (e.g. in a router or gateway box) or firewall software running on one or both of the client machines.
This is not the sort of thing that it is sensible to implement in Java.
EDIT - in response to this followup
I am aware that such a thing is not advisable in Java..but still ill have to implement it..so is there any means to do so..?
Let us assume that you are talking about implementing a client-side firewall on a Linux machine. I can think of two approaches:
You could use Process.execute() and friends to run the Linux iptables(8) admin utility which manipulates the OS kernel's network packet filters. This is the simplest Java-based approach. But it requires that your Java app runs as root.
You could reverse engineer what iptables(8) is doing to manipulate the packet filters and code the same functionality in Java. That would be more coding work, including implementing parts of the functionality in C via JNI or JNA. And your app needs to run as root.
But a far, far simpler approach is to simply run iptables(8) from the command line, or make your changes using the fancy GUI-based admin tools.
Note that in the scenarios above, the firewall itself is not implemented in Java. All you are doing is administering the firewall from a Java application. I cannot think of ANY way to actually do the filtering / blocking in Java that is even remotely practical.
You may need some arp attack things to redirect packets from CLIENT-A to Client-C instead of CLIent-B.
I don't think this is a good idea.
If you are reading the packet on the network on Client C, Client B has already received it so it is too late to block it. If you are using switched ethernet, then Client C wouldn't even see the packet that was sent to B anyway.
The only way to do this is to have A communicate to B through C then C can decide if packets should be sent. This is called a firewall. Instead of writing one, you could use iptables on Linux to do this.
But to make use of this, you need to understand how the network works and I'm not sure you do at this point based on your question. So you will need to learn a lot about ethernet (assuming you are using ethernet) and the different networking layers. I'm not sure of a resource for this.