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

时间:2013-03-12 17:40:52

标签: python sockets air stdout stdin

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

但是,由于我正在编写一个桌面应用程序,我认为维护和修改使用标准流而不是套接字的系统可能更容易。服务器将连续监听raw_input(),并根据写入stdin的任何内容输出,在这种情况下,客户端将使用AIR的NativeProcess类来读取和写入stdout和stdin,而不是使用插座。

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

每种方法的优缺点是什么?使用套接字会增加或减少什么,与使用标准流进行通信会获得或失去的相比?哪一个更有效率?哪一个更容易维护?

1 个答案:

答案 0 :(得分:4)

在类UNIX平台上,使用stdin / stdout是一个套接字,所以没有区别。也就是说,如果你启动一个重定向stdout的进程,那通常是用socketpair完成的,所以不需要让你自己的UNIX域套接字进行通信。用于处理stdin / stdout的Python类不会让你访问底层套接字的完全灵活性,所以你必须自己设置它我想如果你想做半关闭,例如(Python)不能提供跨平台,因为Windows sys :: stdin不能是套接字,例如,也不能始终在UNIX上。)

本地TCP连接的好处在于它是跨平台的,并且在任何地方都提供可预测的语义。例如,如果你想能够关闭你的输出并仍然从输入中读取,那么使用各种各样的套接字做这种事情要简单得多。即使没有它,为了简单起见,使用TCP套接字总是一种合理的方法来解决古怪的Windows混乱的命名管道,尽管Python可以很好地保护你。

相关问题