I'm planning to split my current Java 7 application into server and client side. Server and client side should communicate using sockets.
Basically:
1) Client sends request to the server through a port.
2) Server generates JSON response and sends that response back.
3) Client should deserialize JSON.
Now, the problem is that response JSON is about 1MB in size! I have a limited experience with Java sockets and also communication with server needs to be language-agnostic so I'm not sure which type of stream should I use?
May I use GZipOutputStream (if produced results can be unzipped by GZIP lib from any language)? Should I use something else?
Please give me some advice :)
If plain socket is the only option then yes, using GZIPOutputStream is a good solution. It will generate a gzip format that is standards-compliant and thus readable by any language or tool supporting the gzip compression format.
If your client is java as well, you can use GZIPInputStream to decompress and get the json text back out.
A challenge will be implementing the socket server and (to lesser extent) the socket client code. I recommend to google for code examples and adjust them to your need.
I would recommend to use http protocol instead of plain socket. Implement your server on an application server, such tomcat or jetty. They are very easy to setup up.
To implement the client side, you can use apache http client.
An advantage of this approach is: You don't need to program http compression. You can configure it in tomcat. The http client will automatically decompress for you.
Related
I am developing a MMORPG game for Mobile (mostly windows mobile 8.1), I have written the server using Java and client side using C#. I am using JSON objects for the communication between server and client. I have a TCP connection and a UDP connection.
The mechanism I am using right now is that I send a Request object to the server and waits for a response Object. Rather than this is there a good high level communication library or something that I can use just to make it easier and effective. ?
I suggest you stream asynchronous events and only do request response when your game cannot continue unless you have a response e.g. login.
You can use netty on the server and any one of a number of JSON libraries on the JSON side. I imagine C# has a similar range of communication and JSON libraries.
i want to develop client that bind to icecast server just like butt or edcast but using java, I've found some library like jshout,libshout but I cant make it work in windows ;(, so I'm thinking not depend to some library, I got some information how to stream to icecast server from this link Icecast 2: protocol description, streaming to it using C# , my question is how o send the binary stream data to icecast server? should i using socket or there's another way to do that?
Thx
It's a simple HTTP 1.1 PUT request (just for now without chunked encoding) if you are running Icecast 2.4.0 or newer.
Once the connection is established, you just keep sending data from your encoder/muxer.
If you want to know what headers to send etc, then looking at libshout sources should help.
Is it possible to read datastream sent from C++ server program to C++ client over socket connection in java? I have details like port number and server IP.
Or do I need decompile the whole C++ client into Assembly and then somehow translate it into java to do that?
I'm really not sure what kind of data it's transforming, though.. Somebody told me to code HTTP server and run it on my Router but I'm not really sure if that would work?
Here’s the diagrammatic way to look at it.
Server generates data.
it puts it in a packet.
it encrypts the packet.
and sends it over the wire.
It gets to a user’s Computer (= client). (I should be in the control now on..)
(If I could somehow read data at this part?)
The client reads the encrypted packet.
(If I could somehow read data at this part?) (The later, the better :D)
The client decrypts the packet.
(If I could somehow read data at this part?) (The later, the better :D)
The client does something.
As said, the client is .exe file and it's coded using C++. And I don't have source code of it.
All you have to do is define well your application protocol. This is, the format of your data stream. As long as you are using the same format in both ends, it doesn't really matter what language or program you are using. Imagine your browser and the web server. They are both using the same application protocol (HTTP) but they are completely different programs. Even more, there exists different web servers and different browsers.
Then, all you need to do is use the java sockets to listen to some specific port, and use your c++ sockets to write to the specific port. Just make sure you know how the information is "organized".
I am practicing some web-apps technology. I setup Apache HTTP server which provides HTTP page with JNLP/FlashFX file with simple data-form to fill by the user. My first idea was to send/receive the data from JNLP with help of UDP (I just serialize object inside datagrams). To be more specific:
Apache provides a static HTTP and JNLP/FlashFX (HTTP is just to deploy JNLP)
JNLP communicates via UDP with server
server runs simple Java program to send/receive UDP packets to JNLP
My problem is when I access the page from 'client' browser machine a firewall asking if I want to allow/deny the access to network from 'java'. No doubts this is normal, but I think no one is expecting this from a web page.... I want to change this approach and use existing HTTP protocol.
QUESTION UPDATE
As far as I understood with HTTP protocol we have couple of methods which are used to communicate with the server (GET, PUT, POST .... ) and provided by Apache service.
I would like to use this for data exchange like this:
JNLP sends some serialized data with HTTP methods
Apache will redirect some (or full) traffic to my Java program
My Java program will answers via Apache to my JNLP
How can I do that?
Here is the situation. There are server and client in network. They communicate like this:
Client sends request for some function.
Server sends to client function parameters.
Client trying to perform function and sends answer to server.
Server sends to client data which it should show.
But sometimes client can't perform function and sends error. I want to catch all packets from step 2, analyze them (I've already have tools for that), prevent some of them to reach client, process them with my program and form packet like in step 3. This must be done on client side. I have no access neither to server nor to client.
So, the question is: Is there libraries for changing, injecting and removing tcp/ip packet in c++ or java? The solution should be working in both Win and Linux systems.
Also, may be you have better ideas to expand client functionality?
Thanks for any help!
I tried to google how to change packets, but all I got were unanswered questions and sniffers=(
Edit: Actually, I don't really need injecting and removing packets, I can manage it with only changing packet data. Also, there is no multiple requests in the same packet, and a single request across multiple packets is not a problem.
You have to build a Proxy for your server. The client connects to the proxy, and the proxy itself connects to the server. It just routes all the packages between client and server.
BUT it is now able to intercept specific messages and to modify them. Imagine a filtering HTTP proxy, it works the same way.
I have personal experience with libpcap on linux and freeBSD, a kind of lowlevel library that helps to catch or inject packets. I did use it in an IPV6 network bridge project... But i know there is a windows port for it.
http://sourceforge.net/projects/libpcap/
You can let the library to:
catch packets using a filter
extract data from packet
you can process the data (modify them)
reinject it again using the same library
But you would have to work with internal data in a quite raw matter. Best documentation for this library are comments inside its header file, that is the most up to date info. Maybe there are some more comfortable highlevel libraries.