Armadilloフォーラム

工藤様

オニコスの中山と申します。

> そもそもこういう目的（接続数を制限する）には listen()は使えないのでしょうか？

listen()のbacklog引数は、全体の接続数を制限するものではなく、
一時的な接続要求の待ち行列の大きさを指定するものです。
コードの中で、accept()を呼んでいるところがあるとおもいますが、
一度accept()が成功したら、その後は、そのコネクションが切断されるまで、
accept()を呼ばないようにするのがよいと思います。
切断されたら、再度accept()を呼んで待機します。

> 工藤＠NCPLと申します。
> Armadilloと言うよりもソケット通信全般の話になりますが、
> 表題の「int listen(int socket, int backlog); のbacklogの値と実際のconnect()可能数」についてお伺いします。
>
> Armadillo側でソケット通信サーバを動かして、外部から接続して通信を行おうと考えております。
> 1つのクライアントと接続中に別クライアントからconnect()が試みられた場合
> 別クライアント側で connect()にエラーを返したい
> と思いまして、listen()の backlogで接続可能数がコントロールできるのではと考えて
> listen( socket, 1 );
> とか
> listen( socket, 0 );
> とやってみたのですが、１つ目のクライアントと通信中に別のクライアントでconnect()を試みると成功します。
> （最初のクライアントがソケット閉じると再度待ち受けに戻って次のクライアントと通信が始まります。）
>
> そもそもこういう目的（接続数を制限する）には listen()は使えないのでしょうか？
>
> 実用的には connectできてもサーバ側は複数接続対応に作ってないため
> クライアントからWriteしてレスポンス返送待てばタイムアウトでつながってないのは検出できるので
> 通信できない状態のままブロックしてしまうことを回避する手はあるのですが
> なんとなくすっきりしないので投稿しました。
>
> どなたかこの辺について詳しい方に、何処が間違ってるのかのご指摘をいただけると幸甚です。
>

中村です。

> 1つのクライアントと接続中に別クライアントからconnect()が試みられた場合
> 別クライアント側で connect()にエラーを返したい
> と思いまして、listen()の backlogで接続可能数がコントロールできるのではと考えて
...
> 実用的には connectできてもサーバ側は複数接続対応に作ってないため

そういうこと、ありますよね。
私も何度か同じことを考えたことがあります。
サーバ側の都合で同時に２つを相手にできないようなときです。
で、相手を待たせたくもない、と。

backlogを私もいろいろ調べたのですけど、backlogは結局あきらめました。

古い実装の情報になりますが、「UNIXネットワークプログラミング〈Vol.1〉」
http://www.amazon.co.jp/dp/4810186121
の"4.5 listen"にbacklogの話が詳しく出ています。
いろいろなUNIX系OSのbacklogの挙動を調べていて、それよると、
実装依存なところがあるようです。
この本はかなり古いので（作者もお亡くなりになってますし...）Linuxの
バージョンはまだ2.0.xのころですが、その当時、backlog=0にすると
キューイングされるコネクションは0だったようです。
ですが、BSDとかHP-UXとかSunOSとかSoralisとかは、backlog=0でも
１つはキューイングしていたようです。
（キューイングするとしないとでは大違いなので、backlog=0は使うな！と
書いてあります。その当時の話としてですが...）
で、linuxは2.2のあたりでbacklogの実装が変わりました。
どう変わったのか知りませんが、そのときにキューイングがゼロというのが
ゼロじゃなくなったのかも。。。

これじゃぁ、ぜんぜん回答になってませんね。スミマセン。

> クライアントからWriteしてレスポンス返送待てばタイムアウトでつながってないのは検出できるので
> 通信できない状態のままブロックしてしまうことを回避する手はあるのですが
> なんとなくすっきりしないので投稿しました。

これがあまり気持ち良くない、というのもわかります。

私の逃げ方は、サーバが同時に２つを相手にすることができないときでも、
並行サーバにして接続してきた相手にはすぐにaccept()してあげて、
"BUSY"(を意味する適当な)応答を返すようにしてます。
"BUSY"を返して、すぐに接続を切ってしまいます。
こうすればクライアントは待たずに「あ、今忙しいのね」とわかります。

--
なかむら

> そもそもこういう目的（接続数を制限する）には listen()は使えないのでしょうか？

使えなさそうです。0を指定しても、カーネル内部で最低数のエントリーを持つ
ような実装です。

net/core/request_sock.c::reqsk_queue_alloc() で、
SYNC_RECV を保持する数を決めているようです。

int sysctl_max_syn_backlog = 256;
 
int reqsk_queue_alloc(struct request_sock_queue *queue,
                      unsigned int nr_table_entries)
{
        size_t lopt_size = sizeof(struct listen_sock);
        struct listen_sock *lopt;
 
        nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
        nr_table_entries = max_t(u32, nr_table_entries, 8);
        nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
        lopt_size += nr_table_entries * sizeof(struct request_sock *);
        :
        :