RSH的网络通信细节

那么 rshd 如何检查端口？ client 向 server 发送如下请求数据 :

[port]\0<client_user>\0<server_user>\0<command>\0

Port ---- ANSI 字符串形式的端口号，不是短整型形式的端口号。

client_user ---- 客户端当前用户名

server_user ---- 试图远程使用的服务端用户名

command ----  试图远程使用的服务端命令

port 本身是可选项。如果指定了 port ，服务端会建立到客户端这个端口 (port) 的 TCP 连接， rshd 会将 stderr 重定向到这条连接上。 *nix 要求 port 在 [1,1023] 上，并且成功建立连接，否则服务端进程终止。但这是实现相关的， Solaris 、 Linux 自带rsh 命令，抓包表明它们都提供 port 字段，并且没有命令行开关改变这个行为。

server 向 client 发送如下响应数据 :

<ret><data>

ret 等于 0x00 表示成功， data 对应执行结果，一般是 \n 分隔、结尾的文本。

ret 等于 0x01 表示失败， data 对应错误信息，一般也是 \n 分隔、结尾的文本。

Application reaches max limit on rsh connections

It appears from the customer's application that it is reaching the max limit (and even going beyond) on the max allowed number of port connections when doing repeated rsh to the server's in.rshd,-  which allows connections only from the "ephemeral" reserved ports (ports 512-1023).

Many Error Messages of the kind below appear in /var/adm/messages for 5-10 minutes, and, after which connections start to work again.  Customer is getting these error messages at peak load times.  His ultra is a ftp/rsh/rcp server for many differnt remote client machines.

Error msg example: (/var/log/messages)

"Apr  1 11:07:10 asncomm rsh[16295]: can't get stderr port: Resource temporarily unavailable"

The message isn't from xinetd throttling too high of a connection rate. It is from rshd, due to a failure of rresvport. Note that the EAGAIN associated error message translation is documented on the manpage for rresvport:

      “The rresvport() function returns a valid, bound socket descriptor on success.  It returns -1 on error with the global value errno set according to the reason for failure.  The error code EAGAIN is overloaded to mean ''All network ports in use.''

参考： rsh的网络通信细节

http://www.netexpert.cn/thread-3717-1-1.html

本文转自 zhenjing 博客园博客，原文链接：   http://www.cnblogs.com/zhenjing/archive/2011/04/20/2021766.html，如需转载请自行联系原作者