In Unix like operating systems, we can access serial ports through files such as /dev/ttyUSB0 or something. And according to this question, filenames such as COM1: can be used to access the serial ports. What is the java alternative for such file names? I don't want to use Serial Communication liberaries.
Edit
What I want my code to look like is this.
String INPUT_PORT_FILE_NAME = linux?"/dev/ttyUSB0":"<File name of comport>"
File in = new File(INPUT_PORT_FILE_NAME)
What I want is the widows alternative to a device file.
EDIT
I am on a linux machine, and I want to enable my code to be ported easily!
Yes, on Linux there is access to serial port for instance through device files /dev/ttyS0, /dev/ttyUSB0 and others. It really depends on hardware/chips used to communicate and even distributions.
If same hardware is used in your program it can be partly achieved. When I worked with Serial Comm libraries and real physical serial ports in Linux I used port numbers in config so number 3 meant n=3, so opens "COM"+(1+n) on windows or "/dev/ttyS"+n on linux. Maybe similar can be used for you to accessing port on /dev/ttyUSB"+n
But there is no grantee that port 2 will be /dev/ttyS1 and COM2 on the same computer after dual boot.
The way not using Serial Comm libraries is hard way and do not recommend it if you want portability in java. I recommend different port config depending on operating system.
Related
I have an issue I can't manage to solve.
What I know :
Some information about the process I'm looking for : It's a java process but if I have access to information similar to what's in ps -ef | grep java, then I can find it's PID.
The IP address of a remote machine running Linux version 3.16.7-35-desktop (SUSE Linux)
I would like to find the port used by that process on that machine, with some constraints :
Must be done programmatically, in java
Must work from Windows and Linux (if needed, the java code could handle both cases separately)
Doesn't require to install any other application (neither on the caller machine nor on the remote one)
I also know the port should be between 10000 and 20000. I have network access to the remote machine (both machines are on the same subnet).
How would you do that ?
Note : I found this, but it's old and not remote.
This is a standard hacking requirement. You can do do what nmap does.
Connect to every port in the range in turn and try to determine which the service is this listens to or responds to that port based on the data you get from the service as you connect. It is very slow and will look like a hack if you have any tools to detect this, but it is a technique which has been in use for a long time as it is the only way to do this without a service to tell you what is running on that machine.
A much better approach is to have a service discover process somewhere which has all the services you can contact, ideally with their status so you can easily find one which is available to your client.
Has anybody successfully interfaced Medical Lab devices like Cell Counters /ABG instruments to mirth connect using ASTM 1381-02 or similar protocols over serial port. I am working on a small project. I need the data transmitted by the machine in ASTM format to a text file/ to a database and I cannot afford to pay $30000 for mirth commercial support. I need a low cost or open source solution.
I was expecting MLLP listener to be off use but it seems to work with TCP and I have to make it work purely on serial communication.
Secondly
I tried writing ASTM serial data receiver in Java. But control characters such as ACK, STX, ETX, ETB, and other delimiters are not visible in terminals be it in Win 7 cmd or Netbeans/Eclipse console. Making me helpless in parsing the data.
Any help will in right direction be deeply appreciated.
If you are under Linux environment you may use COM port redirector to a given TCP port and use Mirth's TCP Listener to intercept that flow.
E.g., to pipe the serial port through netcat:
netcat ipaddress port < /dev/ttyS0
Or using socat:
socat pty,link=/dev/virtualcom0,raw tcp:ipaddress:port&
(check for correct parameters)
I recognize 2 problems:
First, is it possible to raise an ftp service on the windows PC? if so, you only need to create a file reader addressed to ftp to capture the txt with the ASTM.
Second, to determine the characters of start and end of message I recommend you read the information of the provider, if you do not have it available, I suggest you use notepad ++ to see the hidden features. I hope you help.
Just FYI there is a commercial extension available that provides ASTM E1381 support: https://www.nextgen.com/products-and-services/integration-engine?extension=astm-transmission
I'm new to embedded systems,
could i send data from java application on my pc to serial 7 segment display direct via serial port or i have to use micro-controller in between
"TTL serial communication" probably means the same protocol used by a PC serial port, but at a different voltage.
You will be able to connect it to a serial port if you use a level shifter in between to convert the voltages. Search for "MAX232" chips, which are designed to do exactly this. There will be a bit of wiring involved. For more help with this part, try https://electronics.stackexchange.com/
On the software side, I don't know if Java has a way to access serial ports. There is probably a 3rd-party library to do this, but C might be better-suited anyway.
I started with requirement of reading and writing files in from/in a directory on a remote Ubuntu machine.
First, I wrote a Java program that could read,write files from a shared folder on a remote Windows machine i.e on a LAN. Here, something like this works on my(local) Windows machine :
File inputFile = new File(
"\\172.17.89.76\EBook PDF");/*ignore the syntax errors, the loc is just for the idea*/
Now when I consider a remote Ubuntu machine, obviously I cannot do something like this as the machine is not on the LAN(I'm not sure if that can be done even if it is on the LAN!). Hence, I tried following approaches :
Using Jsch, establishing the trust between two machines(local - remote Linux , remote Linux - remote Linux) and file writing using sftp.(done)
Running sockets on the two machines - one sender, one receiver(both Java)(done)
Attempting to achieve I/O alike the code snippet for Windows (LAN) machines(not achieved)
While doing all these, I had many queries, read many posts etc. and I felt that I'm missing something on the fundamentals :
Some sort of trust-building(between two machines) utility will be required to achieve IO. But finally, I want to write a code like the snippet given, irrespective of the machines, network etc.
The Jsch solution and the others suggested(usage of http, ftp etc. over URL) finally are using some services that are running on the remote machine. In other words, it is NOT THAT Java IO is being used to access the remote file system - this doesn't appeal to me as I'm relying on services rather than using good-old I/O.
Samba, SSHFS too popped onto the scene, only to add to my confusion. But I don't see them as the solutions to my objective !
To reiterate, I want to write a code using Java I/O(either plain or nio, both are fine) which simply can read, write remote files without using services over protocols like ftp, http etc. or socket sender-receiver model. Is my expectation valid?
If not, why and what is the best I can do to read/write remote files
using Java?
If yes, how to achieve the same !
P.S : Please comment in case I need to elaborate to pose my question accurately !
To answer your question - No, your expectation isn't valid.
Retrieving files from a remote server is inherently reliant on the services running on that server. To retrieve a file from a remote server, the remote server needs to be expecting your request for a file.
The cases you listed in your question (using jsch and sftp, using a sender and receiver Java sockets) that you have achieved already, are essentially the same as this:
File inputFile = new File(
"\\172.17.89.76\EBook PDF");
The only difference is that Java is using the native os's built in support for reading from a windows style share. The remote windows machine has a sharing service running on it (just like Samba on linux, or a java socket program) waiting for your request.
From the Java API docs on File (http://docs.oracle.com/javase/6/docs/api/java/io/File.html)
The canonical pathname of a file that resides on some other machine and is accessed via a remote-filesystem protocol such as SMB or NFS ...
So essentially "Good old Java I/O" is more or less just a wrapper over some common protocols.
To answer the second part of your question (what is the best I can do to read/write remote files using Java?), that depends on what remote system you are accessing and, more importantly, what services are running on it.
In the case of your target remote machine being an Ubuntu machine, I would say the best alternative would be to use Jsch. If your target machine can be either a windows machine or a linux machine, I would probably go for running Java sockets on the two machines (obviously dependant on whether you have access to installing your app on the remote machine).
Generally speaking, go with the common lowest denominator between your target systems (in terms of file sharing protocols).
If you want to access a filesystem on a remote computer, then this computer has to make his filesystem available with a service. Such a service is typically a background job, which handles incoming requests and returns a response, e.g. for authentication, authorization, reading and writing. The specification of the request/response pattern is called a protocol. Well known protocols are SMB (or SAMBA) on Windows or NFS on UNIX/LINUX. To access such a remote service you mount the remote filesystem on the level of the operating system and make it available locally as a drive on Windows or as mount point on UNIX.
Then you can access the remote file system from your Java program like any local file system.
Of course it is also possible to write your own file service provider (with your own protocol layer) and run it on the remote machine. As transport layer for such an endeavor sockets (TCP/IP) can be used. Another good transport layer would be the http protocol, e.g. with a restful service or something based on WebDav.
We used sshfs. You can add to /etc/fstab the line:
sshfs#user#remoteAddress:remoteDir /mnt/ssh fuse defaults 0 0
and then mount /mnt/ssh
I think RMI might be the solution, you could set up a server an RMI server on the machine you want to connect to, and use your machine a the client.
I would give the client a path to the file this will be sent to the server, the server could then read in the file as bytes and sent the file back to the client.
If you create a TCP client socket with port 0 instead of a non-zero port, then the operating system chooses any free ephemeral port for you. Most OSes choose ephemeral ports from the IANA dynamic port range of 49152-65535. However in Windows Server 2003 and earlier (including XP) Microsoft used ports 1025-5000 as the ephemeral range, according to their bind() documentation.
I run multiple Java services on the same hardware. On rare occasions, this range collides with well-known ports that I use for other services (e.g. port 4160 for Jini discovery). While rare, this has caused real problems. Is there any easy way to tell Windows or Java to use a different port range for client sockets? Microsoft's docs indicate that I can change the high end of that range via the MaxUserPort TcpIP registry setting, but I see no way to change the low end.
Update: I've made some progress on this. It looks like Microsoft has a concept of reserved ports that are exceptions to the ephemeral port range. There's a registry setting that lets you change this permanently and apparently there must be an API to do the same thing because there's a data structure that holds high/low values for reserved port ranges, but I can't find the actual function call anywhere... The registry solution may work, but now I'm fixated on this API.
Update2: I accepted a solution on ServerFault for how to do this via the Windows registry. I'd still like a way to do it via API, but I guess I'm satisfied for now.
It's not as elegant as using OS support for ephemeral ports, but the docs show that you should be able to specify a port for your socket to bind to. Specify a port at the base of the range you want and if it is used an exception will be thrown, in which case increment the port and try again. Given that windows isn't using the port range that you want, there shouldn't be many collisions.