Serial communication (RS232) between two applications on the same computer (serial loop back)

Question

I have an application (App1) which just gives input data from serial port. I don't have any external device which sends input data through serial port to the application, so I want to make a java application (App2) which can communicating through serial port with first app (App1) for sending input data to App1. But I don't know how can communicating with serial ports between two applications. It's like local network communication with socket programming on 127.0.0.1 IP (Loop back). I know there are libraries like RXTX and jSSC but I could not find anything like loop back with serial port in their documentations. Can you give me a solution? Thank you.

Simple diagram: |App2| =======(serial communication)======> |App1|

Answer 1

No JAVA content in this answer, just years of bitter experience...

There's a bit more to serial communications than meets the eye if you're used to sockets.

Null Modem Cable

You'll need two serial ports on you computer, one for each application. You will need a null modem cable to join them together. There is no internal loopback for serial ports, you have to go via a cable.

Baud, Parity, etc

Then you have to pick a baud rate, number of stop bits, and what parity to use. You even have to say how big a word is - 5, 7 or 8 bits (5 is very historic, 7 less so, 8 is the norm these days). These have to match either end otherwise the applications won't be able to communicate. Each application has to set up their serial port.

Handshaking

You then have to decide what handshaking mechanism to use - XON/XOFF, hardware or none. XON/XOFF is no good if you're sending binary data, but needs only RX/TX/GND wires. Hardware is better if correctly wired and correctly set up in the applications. A lot of crummy cheap USB serial port adapters don't do hardware flow control properly. No handshaking at all is easiest to get going, also needing only RX/TX/GND, but is hardest to live with in software; if one application isn't reading whilst the other is writing, the data gets lost.

Synchronisation

Then you have the synchronisation problem. You have to write your applications so that they can synchronise with each other. If you have chosen no handshaking, there's nothing to stop app2 sending before app1 is ready to listen. Sure, you can start app1 before app2, but that's kinda unsatisfactory, and doesn't work if you have two way communications (data going in both directions). You can't start both apps first.

Start up

Then there's the problem that even if you are using hardware handshaking in your applications, there's no guarantee that the serial ports are set up by the OS that way before you run them. For example, you may start app2 first, and the serial port for app1 may be saying "clear to send" because the OS has app1's serial port set up that way before you've had a chance to run app1. App2 thinks that it can send and does so, before app1 starts up, configures the port, and only then does app2 realise it's send data too early, and data has been lost.

In short, you need some synchronisation protocol between apps involved in two way communications so that they can be sure that the app the other end is really there and really listening.

This is a lot harder than using a socket. With a TCP socket, the stacks ensure that data only flows if there's something the other end ready to read it.

You could have a "start now" button on the applications' user interfaces. The user can then tell each application that the other is running and that the cable is plugged in.

Conclusions

Serial ports are much more annoying to use than a socket!