LINUX: Is piping across a LAN possible? If so, is it desirable? What are some other options?

I am currently working on creating a scalable server design in C++ for a ubuntu server. Is piping across a LAN achievable? What is the best option for speedy inter-LAN communication?

Background Info for those interested: I'm making a multiplayer game with a friend. It's going to be TCP based. The thing is for linux making a server be multi client seems to mean creating a new process per client or select()ing through a fdset of connected clients. I want to combine these approaches and have a "manager" process that will select through maybe 100 clients and report any changes up the chain to a "taskmaster" process which will then distribute the change to the other manager processes. This will work fine with piping if the managers and taskmasters are on the same box, but if I want to scale it later I n开发者_开发问答eed a speedy inter-Lan communication method.

---

Checkout the netcat application. On one machine, you can run netcat as a server, piping the output to your process:

nc -l -p 1234 | myApp

This will listen on TCP port 1234, and print everything it receives out over stdout.

And on a second machine:

myApp | nc 192.168.1.2 1234

Where 192.168.1.2 is the IP address of the first machine. You'll need to look up the nc man page for the specific details - the above is all from memory.

---

A stream socket (SOCK_STREAM, combined with AF_UNIX if stricly local or AF_INET if over tcp/ip) is the network equivalent of a bidirectional pipe, with all data ordered.

---

Just the way you are asking that question, you seem to have the perception that for communication between related processes, pipes is the necessary answer.

The way to think about it is that you need communication between two processes, whether they be a couple of components in your system, client server pair, or whatever. Then you pick a mechanism that works for the given geography. Pipes work if the processes are local. You could also use shared memory queues for a no copy channel. You could also use IP (via sockets) over the loopback interface. To go across the network (WAN or LAN) you pretty much have to use IP.

Lastly, in addition to TCP, consider using UDP as well, because you get builtin message boundaries and easier endpoint management.

---

LANs typically are Ethernet based networks. This means that any protocol running on your network must be Ethernet based. TCP/IP can and does run on Ethernet networks but pipes and Local sockets are only designed to be an inter-process communication on a single host so is totally not suitable for multi-host applications.

If the various components run on different host, you will need to link them via some TCP/IP based protocol. There are some legacy protocols like IPX and UUCP that run over Ethernet but these have been totally superseded by TCP/IP.