Python 用于本地客户机-服务器通信的套接字与标准流

我有一个由本地“服务器”和GUI客户端组成的应用程序。服务器是用Python编写的，而GUI是可以更改的，并且是用Flex4编写的。客户端向本地服务器查询信息并相应地显示。这两个应用程序都要在同一台计算机上运行，并且只能在本地通信。此时，客户端和Python服务器通过一个基本套接字进行通信，客户端向套接字写入请求，套接字返回一些数据

然而，由于我正在编写一个桌面应用程序，我认为维护和完善一个使用标准流而不是套接字的系统可能更容易。服务器将持续侦听

raw_input（）

，并根据写入stdin的任何内容进行输出，在这种情况下，客户端将使用AIR的

NativeProcess

类来读写stdout和stdin，而不是使用套接字

客户机和服务器是独立的进程，但应该或多或少同时启动。我真的不需要复杂的网络，只需要本地跨语言交流

---

每种方法的优缺点是什么？与使用标准流通信相比，使用套接字会有什么好处或坏处？哪一个更有效？哪一个更容易维护？

在类似UNIX的平台上，使用stdin/stdout是一个套接字，所以没有区别。也就是说，如果您启动一个进程并重定向其stdout，那么通常会使用socketpair来完成，因此不需要创建自己的UNIX域套接字来进行通信。但是，用于处理stdin/stdout的Python类不能让您访问底层套接字的全部灵活性，因此您必须自己设置它，例如，如果您想进行半封闭式操作，我想（Python不能提供这种跨平台的功能，因为例如，Windows sys:：stdin不能是套接字，也不总是在UNIX上）

本地TCP连接的好处在于它是跨平台的，并且在任何地方都提供了可预测的语义。例如，如果您希望能够关闭输出并仍然从输入读取数据，那么使用在任何地方都相同的套接字进行此类操作要简单得多。即使没有这一点，为了简单起见，使用TCP套接字始终是解决古怪的Windows命名管道混乱问题的合理方法，尽管Python很好地保护了您