Unix sockets? You mean Unix domain sockets? That only works on a single host. Perhaps you meant Berkeley sockets, the API for both Internet and Unix sockets. Th

Unix sockets? You mean Unix domain sockets? That only works on a single host. Perhaps you meant Berkeley sockets, the API for both Internet and Unix sockets. This became a POSIX standard and many systems emulate it, even Windows. PVM used them, and built abstractions and new methods on top of the socket APIs to make building distributed parallel-processing applications easier. And Ethernet was, for a time, much more expensive and slower than other solutions, not to mention buggy. It is still slow in some cases (top supercomputers use InfiniBand). Adopting Ethernet was just something that happened due to a confluence of factors (I believe mostly IBM supporting it, and then everyone else, and it becoming cheaper, faster and more reliable over time). So this was just an industry thing, not really a distributed processing thing. The number of nodes is less important than the number of systems - that is, if LLNL wants to do grid computing with CalTech, you're talking about parallel processing over two distinct systems. Even at Google, they may have multiple teams, each with a large distributed system on a different network, and they all have to interoperate. For this, you have to use PVM/MPI, or something similar. This was a significant step in distributed systems engineering. Google didn't need to interoperate with random systems, though, so they didn't need to use PVM/MPI, so their systems were simpler. I think the commodity computing helped them do massive processing cheaper, but at a point there's a lot of waste there, so they engineered out the waste in their new custom systems... which happen to be more expensive and complicated. Everything old is new again.