天天看點

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,如需轉載請自行聯系原作者

繼續閱讀