0

Telnet クライアントが接続に送信するものを出力する Java アプレットを作成しています。残念ながら、クライアントは 1448 文字で分割されます。

問題であることが判明しているコード:

char[] l = new char[5000];
Reader r = new BufferedReader(new InputStreamReader(s.getInputStream(), "US-ASCII"));
int i = r.read(line);

telnet クライアントが読み取るソースを変更できないので、上記の 3 行の問題であることを願っています。

4

2 に答える 2

4

TCP層からtelnetプロトコルデータユニットを取得することを期待しています。それはそのようには機能しません。telnet プロトコルを実装するコードからのみ、telnet プロトコル データ ユニットを抽出できます。TCP 層でのデータのバイトのセグメント化は任意であり、プロトコル データ ユニットを再構築するのは上位層の役割です。

表示されている動作は正常であり、パフォーマンスの問題を診断している場合を除き、データが TCP レベルで分割される方法を完全に無視する必要があります。

于 2012-05-04T01:37:34.477 に答える
1

一度に 1448 バイトしか取得できない理由は、基礎となるプロトコルが送信をパケットに分割するためです。多くの場合、このサイズは約 1500 で、簿記に使用されるバイトがあるため、1448 バイトのチャンクが残ります。プロトコルは、「シングル ショット」で X バイトを送信した場合、クライアントがシングル ショット (たとえば、receive メソッドへのシングル コール) で X バイトを受信することを保証しません。

上記のコメントで既に述べたように、クライアントにとって意味のある方法でこれらのパケットを再構成するのは、受信プログラム次第です。一般に、合意された「データブロックの終わり」マーカー(行末、改行、キャリッジリターン、何らかの記号など)が見つかるまで、受信を実行し、受信したデータを何らかのバッファに追加しますデータに表示されないなど)。

サーバーが本当に telnet サーバーである場合、その出力は行ベースである可能性があります (たとえば、単一のデータ ブロックが「行末」: キャリッジ リターンとラインフィード文字で終了します)。RFC 854 が役立つ場合があります。最初に指定された Telnet プロトコルの詳細が記載されています。

于 2012-05-04T02:03:54.790 に答える