さまざまな方法で、システム上のコネクション型ソケット・サーバーを設計することができます。これらのプログラム例を使用して、独自のコネクション型設計を作成することができます。
別のソケット・サーバー設計も可能ですが、以下の例に示す設計が最も一般的です。
反復サーバーの例では、 クライアント・ジョブとの間で生じるすべての着信接続とデータ・フローを、 単一のサーバー・ジョブが処理します。 accept() API が完了すると、 サーバーがトランザクション全体を処理します。このサーバーは開発は最も容易ですが、問題がいくつかあります。 サーバーは指定されたクライアントからの要求を処理しますが、 別のクライアントもサーバーに接続しようとする可能性があります。 こうした要求で listen() のバックログがいっぱいになって、 結局、一部の要求が拒否されることになります。
並行サーバー設計では、システムは複数のジョブとスレッドを使用して着信接続要求を処理します。 並行サーバーの場合、このサーバーに同時に接続する、複数のクライアントが存在するのが普通です。
ネットワークに複数の並行クライアントがある場合は、 非同期入出力ソケット API を使用することをお勧めします。 これらの API は、複数の並行クライアントのあるネットワークで最高のパフォーマンスを発揮します。
spawn() API は、それぞれの着信要求を処理する新規ジョブを作成するために使用されます。spawn() が完了したら、サーバーは accept() API の上で、次の着信接続を受信するまで待機します。
このサーバー設計の唯一の問題点は、 接続を受信するたびに新しいジョブを作成することに伴う、パフォーマンス上のオーバーヘッドです。 事前開始ジョブを使用する場合は、spawn() サーバーの例のパフォーマンス上のオーバーヘッドを回避できます。 つまり、接続を受信してから新しいジョブを作成するのではなく、 事前にアクティブになっているジョブに着信接続を渡します。 このトピックの他のすべての例では、事前開始ジョブを使用しています。
sendmsg() および recvmsg() API は、着信接続を処理するために使用されます。最初のサーバー・ジョブが開始するとき、サーバーはすべてのワーカー・ジョブを事前に開始しておきます。
以前の API では、サーバーが着信接続要求を受信するまで、ワーカー・ジョブは関係しません。 複数の accept() API が使用される場合は、各ワーカー・ジョブを反復サーバーに変えることができます。 サーバー・ジョブは、以前と同様、socket()、bind()、 および listen() API を呼び出します。 listen() 呼び出しが完了すると、 サーバーはそれぞれのワーカー・ジョブを作成し、listen ソケットを各ワーカー・ジョブに与えます。それから、すべてのワーカー・ジョブが accept() API を呼び出します。 クライアントがサーバーに接続しようとすると、1 つの accept() 呼び出しのみが完了し、 そのワーカーが接続を処理します。