套接字与标准流在本地客户端-服务器通信中的对比
我有一个应用程序，它由一个本地“服务器”和一个图形用户界面（GUI）客户端组成。服务器是用Python写的，而GUI是用Flex 4写的，目的是可以随时更改。客户端会向本地服务器请求信息，并根据请求显示相应的数据。这两个应用程序都是在同一台电脑上运行，并且只会进行本地通信。目前，客户端和Python服务器是通过一个基本的套接字（socket）进行通信的，客户端向套接字发送请求，然后套接字返回一些数据。
不过，因为我在写一个桌面应用程序，我觉得用标准流来替代套接字可能会更容易维护和优化。服务器会持续监听raw_input()，并根据输入的内容输出，而客户端则会使用AIR的NativeProcess类来读取和写入标准输出（stdout）和标准输入（stdin），而不是使用套接字。
客户端和服务器是独立的进程，但它们应该差不多同时启动。我并不需要复杂的网络功能，只需要本地的跨语言通信。
那么，这两种方法各有什么优缺点呢？使用套接字我会得到什么或失去什么，而使用标准流又会得到什么或失去什么？哪种方法更高效？哪种方法更容易维护呢？
1 个回答
在类UNIX系统上，使用标准输入和输出其实就是在用一个套接字，所以没有什么区别。也就是说，如果你启动一个进程并重定向了它的输出，通常是通过socketpair来实现的，所以自己创建一个UNIX域套接字来进行通信其实没必要。不过，Python处理标准输入和输出的类可能无法让你完全利用底层套接字的灵活性，所以如果你想实现一些特定的功能，比如半关闭连接，可能就得自己动手了。因为在不同平台上，Python无法做到这一点，比如Windows的标准输入就不能是套接字，而在UNIX上也不一定总是这样。
本地TCP连接的一个好处是它可以在不同平台上使用，并且在各个地方的表现都是一致的。如果你想在关闭输出的同时还能继续读取输入，这种操作用套接字会简单很多，因为它们在各个平台上都是一样的。即使没有这个需求，为了简化操作，使用TCP套接字也是一个不错的选择，这样可以避免Windows上命名管道的复杂问题，虽然Python在这方面已经做得相当不错了。