目次
では、この問題を本当に解決するにはどうすればよいでしょうか。
1. TCP プログラミング プロセス
ここで注意する必要があるのは、スリーウェイ ハンドシェイクが成功した後は、クライアントとサーバー間に TCP 接続を確立することと同じです。
重要なポイントもあります。スリーウェイ ハンドシェイク プロセスはカーネル内で完了します。! ! 、つまり、プログラマーは、スリーウェイ ハンドシェイクのプロセスに介入するコードを記述していません。
2.機能インターフェース
2.1、監視インターフェース
int listen(int sockfd , int backlog );
2.2. 接続を開始する
int connect (int sockfd, const struct sockaddr *addr, socklen_t addrlen );
2.3. 新しい接続の受け入れを受け取る
プログラムは、完了した接続キューからスリーウェイ ハンドシェイクが完了した接続を受信します。
受信成功のサイン: サーバーは接続用のソケット記述子を作成しました
int accept (int sockfd, struct sockaddr *addr, socklen_t *addrlen);
コネクトとアクセプトの関係
返された新しい接続のソケットはクライアントと通信するためのものですが、このソケットには監視機能がなく、同時にクライアントのアドレス情報を持っています。
複数のクライアントが接続を開始し、サーバー側で新しい接続用の複数のソケットが作成されます
例: サーバーは、ソケットによって作成されたソケット記述子を使用します。これは、新しい接続をリッスンするだけの「pimped」リッスン ソケットと同等です。
accept を使用してサーバーによって作成された新しい接続ソケットは、「顧客を受け取る」シャオホンに相当します. 新しい接続ソケットはクライアントと通信しています.
2.4. 送受信インターフェース
ssize_t send(int sockfd, const void *buf, size_t len , int flags );
ssize_t recv ( int sockfd 、 void *buf 、 size_t len 、 int フラグ );
3. コードの実装
最初にサーバーを書きましょう
最初に listen についてここで書きましたが、
1. ここで、 telnet を介してtcp 監視が成功するかどうかをテストできます。これは、telnet がサーバーに接続要求を送信できるためです。つまり、スリーウェイ ハンドシェイクです。
何も表示されていない場合は、接続が確立されていることを意味します。
次に、再び netstat を使用してポートのステータスを観察すると、もう 1 行の情報が見つかります。
2. tcp のテスト、listen 関数のバックログ、同時接続数の意味
同時接続数が tcp 接続の最大数と等しくありません
もう一度クライアントを書きましょう
書いたら実行してみよう
正常に通信できることが確認された
質問: 複数のクライアントを作成するとどうなりますか?
この状況の理由を分析します。
まず、2 番目のクライアントのコードをプロンプト入力ステートメントに対して実行できます。これは、クライアントがこの時点でサーバーとの接続を確立したことを示します。また、クライアントはデータの送信後にエラーを報告しません。これは、クライアント データの送信が成功したことを示します。したがって、問題はサーバー側のコードにあるに違いありません。netstatコマンドを使用して、現在のネットワーク接続ステータスと関連情報を表示
できます
私たちのサーバー コードが2 番目のクライアントを受け入れなかったことを証明しています。
現在のコードを分析してみましょう。
では、ループにacceptを追加することで解決できますか?
答えはノーです
では、この問題を本当に解決するにはどうすればよいでしょうか。
1. マルチスレッドを使用して解決する
実装原則:
マルチスレッド コード:
2.マルチプロセスを使用して解決する
マルチプロセス コード:
