Please note: Although the library I'm using is called the Java Simple Serial Connector, this question is really more about Java coding against serial ports in general, and any strategies associated with doing so.
I'm using a Java library (JSSC as mentioned above) to read data from a serial port. The library requires you to poll the port for all available bytes. But this has me worried, because in between 2 different poll attempts, data could be streamed to the port (from the serial device) and therefore perhaps "lost".
Unless there is some kind of buffering/caching mechanism at the hardware layer that buffers data coming in to the serial port. In that case, the library's API makes sense, as it probably consults the buffer and reads anything thats been queueing up inside it. So I ask:
Is there such a "serial port buffer"? If so what is it? If not, then are there any strategies to "lossless" serial port reads?
If there is such a buffer, how does it work? What happens when it fills up?
The Java lib I'm using reads serial port data as byte[]'s; does it make sense to then construct a ByteArrayInputStream from these byte[]? What benefits would one gain from doing so?
Related
We are using Java nio AsynchronousServerSocketChannel with completion handlers to write to a socket channel.
The sockets are used to communicate locally between two processes running in a same system.
We tend transfer quite a huge data. We use a buffer size 16384 to transfer the data in a chunked manner. Sending over UDP is not an option.
Is there anything else which can be done to improve the performance of the socket channel or reduce the payload transferred ?
Best Regards,
Saurav
There are a number of alternatives you may consider. I expect that you will need to implement each and test the actual performance on your hardware with your application in order to choose the right one.
You can try to tweak your current approach. Some thoughts: much larger buffer, double buffer (use two sockets so the writer always has a socket available for writing and the reader can always be reading), only send differences (if you are continuously sending and updated version of the data), compression, etc.
Use a completely different approach, such as shared memory or a memory-mapped file. A couple of questions with lots of good answers that may get you started: this and that.
While the details depend on your specific environment, you probably can speed up the communication by 10x (or maybe significantly more) over your current socket implementation.
I have coded a server in Java that will have several clients connected to it. I want to be able to see how much data is sent to each client to be able to make decisions like allowing more clients or decreasing them, or even to increase/decrease the frequency at which the data is sent.
How can I do that?
I'm currently using Java's Socket API, but if any other library gives me this easily, then a change can be done. The server will run in a linux flavor, likely Ubuntu, so a OS specific answer is welcomed too.
When you write data to the socket, you need to remember how much you sent. There really isn't smarter way to do this.
Generally speaking, you would allow the server to have a limited number of connections. Trying to tune the system based on bandwidth restrictions is very hard to get right.
Using java.net.NetworkInterface I am getting the status (up/down) of network.
I want to get the value of send and receive byte on the network card.
And I need to calculate network utilization also.
How to get these in Java?
I don't think there is a pure Java way of doing this.
So one solution is to use JNI and a native library, which of course would have to be OS-specific.
If you want something more portable, I suggest trying out SNMP. All common OS should support querying such data via SNMP (perhaps after installing an SNMP server), and there are also Java SNMP client implementations available.
I would suggest using OSHI. The NetworkIF class supports everything you need.
I am working on a project where I need to convert bursts of data (in the range of 300 bytes) from Iridium's short burst data service . This is meant to replace a dial-up connection, so I need to take those bursts of data from the short bursts and convert them into the continuous stream of a dial-up connection.
I'm a relatively inexperienced programmer, and the only language I know is java.
How could I go about converting the data? Are there any background materials on how types of information packets operate and how to manipulate them in java?
[Edited for clarity]
EDIT2: I do not need to convert the data the other way around (from the stream to the chunks)
Your question is not clear on whether you are writing software to talk to the Iridium transceiver, or whether you are on the server-side, but I will assume you are on the client side since, judging by their website the server side is standard IP networking.
The program talks to the transceiver using an RS-232 interface and the AT (modem) command set. Using Java you will need some sort of serial library; I have had extensive experience with such, in particular with a program to manage a bank of modems bridging their comms to an IP network and at that time the only comms package which worked and was stable was SerialPort from SerialIO. The other potentially viable option is RxTx but when I worked with that several years ago it was unstable and would crash the JVM every few days. With either one you can (and should) constrain yourself to the JavaComm API which will enable you to easily switch out serial libraries.
Once you are talking to your serial port manipulating the transceiver should be the same as manipulating a modem, you will need to refer to the doco for specifics. If it's faithful to a modem, it will operate it two modes, command and data. In command mode you are sending AT xxx commands terminated by CRLF. When you are in data mode you are sending binary data.
The structure of the binary data will almost surely be dictated by the Iridium system, and you will need to conform to that; again see their doco.
If you have the luxury of defining your own data protocol, or if you have free-form messages atop their protocol my best advice is to make your messages logically keyword/value pairs to ensure long-term flexibility. If you are tight on space (and it seems like the size restrictions for Iridiums devices are fairly severe) you could make your keywords predefined (agreed on by client and server) and send a binary integer instead of, say a UTF-8 or ASCII string. The protocol should include or infer a very basic type so that numeric values, especially, can be as condensed as possible.
Anyway, I hope that gives you some direction and ideas of what to expect... please feel free to ask questions via comments, especially for particular questions about using a serial port from Java.
I'm currently translating an API from C# to Java which has a network component.
The C# version seems to keep the input and output streams and the socket open for the duration of its classes being used.
Is this correct?
Bearing in mind that the application is sending commands and receiving events based on user input, is it more sensible to open a new socket stream for each "message"?
I'm maintaining a ServerSocket for listening to the server throwing events but I'm not so sure that maintaining a Socket and output stream for outbound comms is such a good idea.
I'm not really used to Socket programming. As with many developers I usually work at the application layer when I need to do networking and not at the socket layer, and it's been 5 or 6 years since I did this stuff at university.
Cheers for the help. I guess this is more asking for advice than for a definitive answer.
There is a trade off between the cost of keeping the connections open and the cost of creating those connections.
Creating connections costs time and bandwidth. You have to do the 3-way TCP handshake, launch a new server thread, ...
Keeping connections open costs mainly memory and connections. Network connections are a resource limited by the OS. If you have too many clients connected, you might run out of available connections. It will cost memory as you will have one thread open for each connection, with its associated state.
The right balanced will be different based on the usage you expect. If you have a lot of clients connecting for short period of times, it's probably gonna be more efficient to close the connections. If you have few clients connecting for long period of time, you should probably keep the connections open ...
If you've only got a single socket on the client and the server, you should keep it open for as long as possible.
If your application and the server it talks to are close, network-wise, it MAY be sensible to close the connection, but if they're distant, network-wise, you are probably better off letting the socket live for the duration.
Guillaume mentioned the 3-way handshake and that basically means that opening a socket will take a minimum of 3 times the shortest packet transit time. That can be approximated by "half the ping round-trip" and can easily reach 60-100 ms for long distances. If you end up with an additional 300 ms wait, for each command, will that impact the user experience?
Personally, I would leave the socket open, it's easier and doesn't cost time for every instance of "need to send something", the relative cost is small (one file descriptor, a bit of memory for the data structures in user-space and some extra storage in the kernel).
It depends on how frequent you expect the user to type in commands. If it happens quite infrequently, you could perhaps close the sockets. If frequent, creating sockets repeatedly can be an expensive operation.
Now having said that, how expensive, in terms of machine resources, is it to have a socket connection open for infrequent data? Why exactly do you think that "maintaining a Socket and output stream for outbound comms is not such a good idea" (even though it seems the right thing to do)? On the other hand, this is different for file streams if you expect that other processes might want to use the same file. Closing the file stream quickly in this case would be the way to go.
How likely is it that you are going to run out of the many TCP connections you can create, which other processes making outbound connections might want to use? Or do you expect to have a large number of clients connecting to your server at a time?
You can also look at DatagramSocket and DatagramPacket. The advantage is lower over-head, the disadvantage is the over-head that regular Socket provides.
I suggest you look at using an existing messaging solution like ActiveMQ or Netty. This will handle lot of the issues you may find with messaging.
I am coming a bit late, but I didn't see anyone suggest that.
I think it will be wise to consider pooling your connections(doesn't matter if Socket or TCP), being able to maintain couple connections open and quickly reuse them in your code base would be optimal in case of performance.
In fact, Roslyn compiler extensively use this technique in a lot of places.
https://github.com/dotnet/roslyn/search?l=C%23&q=pooled&type=&utf8=%E2%9C%93