I know that the Java can use the Socket Programming to send an Object. Apart from socket programming, anything other way to do it?
Java's Remote Method Invocation (RMI) is probably the easiest and most widely supported way.
Java's Advanced Socket Programming describes marshalling objects over a socket.
Control a high-speed robot hand to type it in.
Pretty well every other thing you can do will be a layer built on sockets.
RFC1149!
Attach rubber band to computer A
Put Object in rubber band.
Pull back, aim at Computer B.
Let go.
Via web service for example. But its build on top on sockets again.
SOAP (Simple Object Access Protocol).
Serialize the object, write to a file, copy the file if the computers are network connected if not use a removable disk and deserialize it.
Objects can be transferred via a shared database.
I work near a production system that's been doing this for 10 years.
Ironically, except in rare cases, DB connections are also implemented via sockets.
No. Sockets are how computers communicate. Other than writing the data to some media and physically transporting it between computers, you will have to use sockets.
At the lowest level, data is transferred over sockets as bytes. So first you need to serialize your object to bytes, then you can send it, then on the other side you need to deserialize the object from the bytes.
Approaching your question less literally, there are Java libraries that handle the serialization automatically and hide the nastiness of dealing directly with sockets. I recommend KryoNet. KryoNet can do remote method invocations, and a lot simpler and more efficiently than Java's built-in RMI support.
Related
I'm making an online game using ObjectOutputStream... to exchange data. Since I have different types of data I'm using the write/readObject() functions only. I was wondering if sending a String for commands was good practice or if there is a better, safer solution.
When I say I send commands with a String, for example I have a chat and I want to ignore a user, so I send to the server "block +username"; if I want to add a friend I send "addfriend +username", etc.
Well, using serialized objects might create lot of interoperability work if you are going for a serious installation. It also can become a bottleneck. I would (besides the obvious of using any other messeging protocol) stick to DataOutputStream if you look for a compact home grown protocol.
Sending strings as serialized java objects is the most suprising thing to do (and wont easily allow you to have client or servers in different languages).
If you want to be cool, use JSON and Websocket. :)
Good day. I develop server-client application with Glassfish+ObjectDB(embeded mode) on serverside and Android application on client side. What is prefreable way (with respect to traffic and security) to send data that stored as java objects in ObjectDB to android application? (Data must be encrypted.)
I think about:
pass serializable objects through stream input/output.
pass data as XML/JSON format.
Or may be there is other way?
Thx for help.
You can try Protobuf http://code.google.com/p/protobuf. Less traffic and easy to be integrated.
Binary data as well has a smallest size, but is less useful. XML is self-described, but has a biggest size.
If you need to send data only between your apps you can choose binary format.
In my project I am doing the first approach.
pass serializable objects through stream input/output.
This means I doing "file" uploads resp. downloads.
However, with this approach your are bound to use Java on both sides (server and android) which is not an issue in my case
Your second approach will generate to much overhead
Encryption should NOT be done on this level. Better use HTTPS
I need to communicate between server/client. I saw that CORBA is used for different languages to work like RMI, is it?
In my application I will have to transfer objects between client/server, transfer binary files (which I saw that I can do with RMI) and also play live streaming from one client to another.
I was thinking about CORBA because it also can be used with C++ if I need, isnt it?
So can I play streaming with CORBA?
RMI and CORBA are technologies for distributed objects. You then invoke methods on a remote object the same way as on a local object.
Sure, you can send and receive bytes if you implement methods that do so (e.g. void sendChunk(byte[] data)). But I wouldn't consider them appropriate for streaming. Also for streaming, you should pick something to address the quality of service of the stream -- which RMI or CORBA definitively don't do. For that I would maybe have a look at UDP sockets, or something like that, which just drops packets if the channel is saturated.
CORBA provides you a lot of services and it possibly is not the best of the options for streaming media. Two reasons I can think of (though one can find more reasons against too)
The object payload is more than just the data (marshalling and unmarshalling)
CORBA (specifically the implementations) generally strive for a good QoS aka there will be retries for the same call
That said, it has been demonstrated that ORBs can work with real-time communication too. So, CORBA as a framework is not completely off the table.
I am not sure of the multicast communication capabilities of CORBA though.
If you're hell bent on using CORBA to address this, have a look at RT-CORBA (Real-time corba). I believe TAO has an implementation of it, however I've never used RT-CORBA so I can't speak first-hand if it'll give you the performance you'll require for streaming.
I need to transfer files fast over the Internet from a Java server to C++ clients, where often many clients would need the same files. I was looking at say transferTo() in Java which sounds like it would be a decently optimized function to send files. However, I'm not sure when I use transferTo() how to best receive that in C++ (i.e. is it just a raw data transfer, how do I determine when the file is over on the client side, etc.). I need this to work on both Windows and Linux. Also, other than transferTo(), would there be some way to be more efficient, especially by taking advantage of the fact that many clients will usually need the same files? I'm not sure how to do say multicast etc. Also, I'm using application-level security rather than a VPN, and on the Java server, encrypting with AES and using MAC digital signing, so I'm also looking for a cross-platform library recommendation to deal with the crypto on the C++ side with minimal pain.
I'm very proficient in C++ but have no previous experience with network programming, so please consider than in any suggestions.
Thanks.
An embedded webserver? http-transfers are efficient enough for you?
The simplest embeddable Java webserver I remember seeing is http://acme.com/java/software/Acme.Serve.Serve.html. We use embedded Jetty 6 in production at work, but that takes more elbow grease.
If your clients doesn't know where to find your webserver in the first place, consider announcing using Zeroconf. http://jmdns.sourceforge.net/
For scalability reasons, Thorbjørns suggestion of using http seems like a very good idea as it would allow you to easily set up http proxies for caching, use standard load balancing tools and so forth.
If you are looking to transfer more than just a blob of data, you might want to have a look at googles protocol buffers. They allow for very easy and fast encoding/decoding on the java and c++ end.
Consider chunking the file and sending via UDP datagram. C++ can re-compile as it receives it. Have you considered implementing/embedding an existing P2P protocol implementation?
If you need effecient transfer to many clients then your bottleneck is the server.
For this please look at the bit-torrent protocol as it distributes the transfer between the clients.
What would be the easiest way to be able to send and receive raw network packets. Do I have to write my own JNI wrapping of some c API, and in that case what API am I looking for?
EDIT: I want to be able to do what wireshark does, i.e. record all incomming packets on an interface, and in addition be able to send back my own created packets. And I want to do it on a mac.
If you start with the idea that you need something like a packet sniffer, you'll want to look at http://netresearch.ics.uci.edu/kfujii/jpcap/doc/.
My best bet so far seems to be the BPF api and to write a thin JNI wrapper
Raw Socket for Java is a request for JDK for a looong long time. See the request here. There's a long discussion there where you can look for workarounds and solutions. I once needed this for a simple PING operation, but I can't remember how I resolved this. Sorry :)
You can't access raw sockets from pure Java, so you will need some sort of layer between your Java code and the network interfaces.
Also note that access to raw sockets is normally only available to "root" processes, since otherwise any user could both a) sniff all traffic, and b) generate spoofed packets.
Rather than write your whole program so that it needs to run as "root", you might consider having the packet capture and generation done in a standalone program with some sort of IPC (RMI, named pipe, TCP socket, etc) to exchange the data with your Java app.
TINI is a java ethernet controller, which may have libraries and classes for directly accessing data from ethernet frames to TCP streams. You may be able to find something in there that implements your needed classes. If not, there should be pointers or user groups that will give you a head start.