netcat
netpipes
bash's /dev/tcp/... (see man bash for details)
socat
inetd
xinetd
daemontools
ssh
stunnel
daemontools/ucspi-tcp
openvpn
and a normal IPSEC VPN
are the major ways excepting things like SOAP servers, Web Services, RPC, CORBA, ODBC, JINI / Java RMI, and such to facilitate communication between peer hosts, or a client and a server.
The /etc/services bit above isn't quite correct, services just gives a service "name" to port number translation table that itself doesn't
do anything else, but you can define arbitrary server processes to run when comminications are established over UDP or TCP links to
a given server machine; you set that up with inetd / xinetd / /etc/services or DJB's daemontools/ucspi-tcp. This is an easy and standard
sort of way to make a server "always listen" on predefined TCP or UDB ports and for that server to hand off the incoming traffic / connections
to defined server applications when traffic does appear.
Usually you'd use netcat / netpipes to establish a pipeline type link to over the network and use the output of the pipe or standard IO channel
the pipe / nc is connected to to input/output to a server process or a file on the server or whatever. Your example doesn't really speak
to how you're plumbing your pipes to server processes or files or whatever. Your examples show the nc *being* the invoked server
process, but by itself it is kind of useless if you don't specify a useful location or additional program on the server that the nc/pipe will
send its output to or take its input from.
These are the typical sorts of configurations, and you'd use command line arguments or a shell script wrapper to set up
any I/O redirections or command line arguments for nc / netpipes / whatever to get the whole thing working.
Client Transmits OUTPUT ---> network ----> Server file being made from data coming over the network
Client Transmits OUTPUT ---> network ---> Server process that reads the data as input
Client Reads INPUT <---- network <---- Server file being sent over the network
Client Reads INPUT <--- network <--- Server process sending its output data over the network to a remote client
If you just want a static set of ports waiting for client connections on the server, check out inetd/xinetd and /etc/services etc.
If you just want a simple pipe type of facility over the network, netpipes, netcat.
If you want some data security and some kind of standardized way to redirect server ports over the network, check out ssh and sshd
and stunnel, they are there to 'securely' transport data from server files or processes to clients. Both the client and server need to have
compatible ssh or stunnel software running, however the ssh facility can take arbitrary server processes or ports and redirect their
outputs and inputs over the network, for instance it is typical to run X windows over SSH, or use SSH to start up a remote bash shell
and have the shell's input / output directed over the network along obviously with any commands the shell runs itself. You can
set up predefined key based authentication between the server and client processes and have particular server processes run
when a given client connects.
If you're doing JAVA ESQUE code on both ends it wouldn't be uncommon to use things like RMI / JINI / CORBA / JDBC / DCE / RPC / J2EE / SOAP/ WSDL type of APIs in the JAVA programs on the client and the server to wrap up the communications layer and make things
work, though the programs would have to be designed to do this sort of thing and sometimes it is more complex than is needed if all
you wanted is socket level TCP/UDP communications.
Of course if you were writing JAVA applications and all you wanted was socket level communications, there are network IO classes that
give you that straight in JAVA without needing any additional utilities like netpipes/netcat, but the programs would have had to have been
written to support such networking of course.
Turn off the firewall blocking of any needed ports of course if there is any.
You could also do things like statically or dynamically set up VPN or PPP links from one machine to the other and in that case all the
ports on one machine's VPN interface could be open to the other machine's VPN interface bypassing things like NAT or firewalls on
the physical network between the machines.
I think if you write yourself a simple script on the server
#!/bin/bash
echo "Hello world"
and then cause it to be invoked by netcat (or set it up as an inetd/xinetd TCP service on a given port) and send its output over the
network that may be a simpler starting point than trying to set up test programs to work if you don't quite understand how to plumb them
into the picture.
Facebook
Twitter