|
|
|
|
data sharing between Java & non-java
Posted:
Aug 14, 2008 9:38 AM
|
|
|
Hello All,
First, if this post is in the wrong forum, please direct me to the right place to post it.
I'm writing a server application to an existing C++ client. The client sends data and images. The number of clients is 50, but could be a lot more. That is why I thought of using java NIO for my server, to scale up for a big number of clients.
- Is it possible to do this, while the client is non-Java?
- and what is an efficient communication protocol between the server and client? "The client will implement the same protocol".
Thank you.
|
|
|
|
|
|
|
Re: data sharing between Java & non-java
Posted:
Aug 14, 2008 12:47 PM
in response to: double07
|
|
|
From the nature of your questions, I'm having the impression that you're new around communication networks. Going on that assumption, allow me to go through some of the basics.
Networks are agnostic with respect to applications. Think of a plaintext file. Whether you open it vi, notepad, or your browser is inconsequential to the contained data. It's the same with networks: your drivers get the data from the network and deliver it to your operating system. They don't even know what application it came from, let alone what language it was written in.
Before you build your server, you must consider the nature of your connections. Is it imperative that the data come across correctly and completely, or is it acceptable that data is lost along the way?
An example of a need for integrity is when viewing documents. An example of an application that may accept some loss is a video conference. Reliable transfer uses TCP, unreliable uses UDP. In Java NIO, TCP is modelled through (Server)SocketChannel, while UDP is modelled through DatagramChannel.
From the sounds of it, you will need TCP.
Java NIO uses a selector paradigm that may need a little explaining. There are some good tutorials around for that, so I'll give only a primer -- the tutorials are better than I am.
A selector is essentially an event listener for channels. When a channel raises an event (e.g. "I have data available") the selector registers this. A thread can then poll the selector, iterate over each channel that reported an event, and handle those that it believes are of interest.
Now, contrary to ordinary (blocking) I/O, where each thread waits on its respective stream, here a single thread usually monitors the selector (also called the selector thread) and invokes worker threads to do the job after signalling. ("This channel is ready for reading; he's all yours.")
This disjoint nature has a number of consequences:
1) Protocol state is no longer local to a thread. Whatever protocol you choose to implement or invent, any and all data needs to be attached to the channel. The Selector class provides support for such attachments. Fire and forget.
2) You'll need a pool of threads (most likely an ExecutorService) to handle channel events. If you let the selector thread do all the work, you may inadvertedly starve connections while it's serving others. Select and delegate.
3) I/O may be incomplete. If there are only 568 bytes in the buffer when you call read, you'll only get 568 bytes. Waiting for more data means saving what you already caught (storing it in a ByteBuffer) and passing it back to the selector.
That's a lot of chewing on your ear already. I hope it's helpful and sensical,
Jonathan
|
|
|
|
|
java.net RSS
