私はサーバソケットプログラミングlinkのためにこのチュートリアルを受け取ります。機能性については、私はそれについては何の問題もなく、私が求めているのはアーキテクチャ設計の問題です。チュートリアルを見てください。実際にはsocket()を呼び出すときと、accept()を呼び出すときのときの2つのファイル記述子があります。ソケットをファイルとして扱うので、ソケットを作成するときにファイルディスクリプタを取得するのは理にかなっています。異なる接続を受け入れるときに複数のファイル記述子を持たなければならないことも意味があります。しかし、なぜそれを機能させるために両方を持つ必要がありますか？なぜTCPサーバソケットプログラミングで2つのファイルディスクリプタを取得する必要がありますか？
第1ソケットはリスニングソケットと呼ばれます。 TCPは接続指向のストリームです。各クライアント接続は、ファイルのように独自のソケットで動作します。ソケットが1つだけの場合、受信したデータがどの接続に属しているかを区別することはできません。だから、TCPソケットの設計は、リスニングソケットをLISTENモードで動作させ、クライアントがサーバへの接続を確立するたびに、accept呼び出しは、新しいソケットを呼び出すために新しいソケット、つまりクライアントソケットを返します。このクライアントとの通信にのみ使用されます。
一方、UDPは、すべてのクライアントからのすべてのデータを処理するために1つのソケットだけが使用されるコネクションレスのデータグラムベースのプロトコルです。
ちょうどこのポストに出くわした：http://stackoverflow.com/questions/20939193/is-new-socket-created-for-every-request、正しいことは、最初のソケットはパッシブソケットですが、 accept（）はアクティブソケットと呼ばれますか？ – TimeString
@TimeString - passiveは正確な単語ではありません。リスニングソケットは、ESTABLISHED接続がない限り、アクティブソケットです。受け入れられたソケットにはESTABLISHED接続がありますが、TTLを保持している限りアイドル状態になる可能性があります。 – alvits
@alvits RFC 793では「パッシブオープン」と呼ばれています。「Keep the TTL alive」は無意味です。 – EJP
1つのソケットがリスニングエンドポイントを表します。もう一方のソケットは受け入れられた着信接続を表します。それ以上の接続を受け入れたくない場合は、acceptを呼び出した後にリスニングソケットを閉じることができます。
それで実際には2つの異なるタイプのソケットを作成しましたか？ – TimeString
はい。これらは両方ともTCPエンドポイントですが、1つはローカルアドレスにのみバインドされるリスンエンドポイントを表し、もう1つはローカルアドレスとリモートアドレスの両方にバインドされたアクティブなTCP接続を表します。リスニングエンドポイントを使用してさらに多くの接続を「受け入れる」ことができます。必要がない場合は、接続を「閉じる」ことができます。 –
@TimeString - 'netstat -ant'を実行することで両方のソケットを見ることができます。実際には2つのソケットがあることに気づくでしょう。 1は「ESTABLISHED」であり、他方は「LISTENING」である。 – alvits
理想的には、2つの異なるTCPエンドポイントです.1つはリスニングエンドポイント（LISTENING）として使用され、もう1つは受け入れられた着信接続（ESTABLISTED）として使用されます。接続を受け入れたら、リスニングエンドポイントを閉じることができます。
偉大なチュートリアルではありません。 'listen（）'はエラーチェックされません。 'send（）'と 'recv（）'を使うことができます。 'インターネット上のサーバーソケットの場合、アドレスはホストマシン上のポート番号と他のすべてのサーバーソケットで構成されます。修飾は無意味です。受信したデータを印刷するときは 'n 'は無視されます。ソケットは決して閉じられません。そこには良いチュートリアルがあります。 – EJP