From nakano.hiroaki ＠ nttcom.co.jp Tue Jul 15 16:00:00 2014 From: nakano.hiroaki ＠ nttcom.co.jp (Hiroaki Nakano) Date: Tue, 15 Jul 2014 16:00:00 +0900 Subject: [Ultramonkey-l7-develop 1055] Re: =?iso-2022-jp?b?UkhFTDcbJEJNUSVRJUMlMSE8JTgkKjtuJDcbKEI=?= In-Reply-To: <53ABDED7.70803@nttcom.co.jp> References: <53ABDED7.70803@nttcom.co.jp> Message-ID: <53C4D170.40306@nttcom.co.jp> 中野@幕張です。 特になにも出ないので、そのうちさりげなくダウンロード場所に 置いてみようと思います。 (2014/06/26 17:50), Hiroaki Nakano wrote: > 中野@幕張です。 > > RHEL7用パッケージを作って、仮置き場に置いてみました。 > http://ultramonkey-l7.sourceforge.jp/_tmp/tmp_uml7_3_1_1-1/rhel7/ > > うまく動かないところ等あれば、教えてください。 > -- 中野 宏朗 (NAKANO Hiroaki) From h-nakano ＠ iwao.net Tue Jul 15 23:06:00 2014 From: h-nakano ＠ iwao.net (Hiroaki Nakano) Date: Tue, 15 Jul 2014 23:06:00 +0900 Subject: [Ultramonkey-l7-develop 1056] Re: [RFP] using SO_REUSEPORT on UltraMonkey-L7 In-Reply-To: <52EF3C87.1010402@nttcom.co.jp> References: <52D77651.3040601@nttcom.co.jp> <52DF7245.7060806@nttcom.co.jp> <52EF3C87.1010402@nttcom.co.jp> Message-ID: <53C53548.7070802@iwao.net> たるすぴです。 v2ベースのfork版、サービス追加部分作り途中です。 結局名前付きパイプで、子プロセスと親プロセスを 通信させて、親から子へはプロトコルモジュール情報を、 子から親へはpidを通知するようにしています。 パイプはiomuxのepollを使ってイベント検知するようにしました。 そして、これまでのサービス管理系GListは子プロセスに もたせて、親プロセスは別のGListでIP+portごとに pidとプロトコルモジュールのリストを管理するようにしています。 もっとも、今の作りだと子から親への通信部分でエラーに なって、親プロセスが消えてしまうバグがありますがｗ ソースはここです。 http://pf.sourceforge.jp/gitroot/h/hi/hiroakinakano/UltraMonkeyL7_v4_nakano.git このバグを取っても、基本部分を完成させるためには ・サービス削除 ・サービス変更 ・プロトコルモジュールのオプションをちゃんと渡す くらいをさらに作らないとです。 さらにSSLだのモジュール分離だの、v3にあった機能を 作りこんだり、過去のチケットを回収したりと先は 長いです(´Д｀) (2014/02/03 15:51), Hiroaki Nakano wrote: > 中野@幕張です。 > > (2014/01/24 5:43), TATEISHI Katsuyuki wrote: >> タテイシです。 >> >> 2014/1/22 Hiroaki Nakano > > >> >> virtual service自体はGLibの双方向リンクリスト >> で管理されてるので、配列とかと違って最大値を >> 事前に設定せずともメモリのある限りアイテムは増やせるはず。 >> epollのmax eventとかに関連があるんでしょうか？ >> >> >> ちょっと横道にそれるんですが・・・半ばひとりごとです。 >> >> v2はオープンできるファイルディスクリプタがmax_eventsで制限され >> ててチューニングに苦労した方も多いかと思います。 >> この変数によってv2が同時にオープンできるファイルディスクリプタ >> 数が制限される、と言われていますが、この制限って必要なんですかね？ >> >> この値、iomuxの中でepoll_createとepoll_waitの引数に使われてますが、 >> epoll_createでは現在使われませんし、epoll_waitに渡す方はあくまで >> epoll_waitから同時にどれだけのファイルディスクリプタを取り出すか、 >> (カーネルに渡すepoll_eventのサイズ)を指定しているだけであってアプ >> リケーション全体のファイルディスクリプタ数がこれで制限されてしま >> うのはおかしい気がしています。 >> # epoll_eventのサイズとEPOLL_CTL_ADDできるFDの数は関係ないですよね >> >> 本来であればepoll_waitでカーネルと一度にやりとりするイベント数 >> (max_events)とアプリがオープン可能なファイルディスクリプタ数は >> 個別に管理されていていいと思うのですが・・・ >> >> # iomux.cのレイヤの都合でそうなってるのですかね。 > > これは調べきれてないのでおいらも疑問のままです。。。 > # たぶん、立石さんの言うとおり関係ない感じ。関係あるのって > # /proc/sys/fs/epoll/max_user_watches　くらいですよね。 > > > まったく話は変わるんですが、v2をIPとportのソケット生成時に > 子プロセス化させるとすると、同じIPとportでprotocol module > だけ違うサービスを後から追加するときに困ることに気が付きました。 > > v3でもそうですけど、UltraMonkeyL7のバーチャルサービスって、 > IPとport以外に、プロトコルモジュールの違いでも別サービスとして > 作ることが可能でしたよね。 > > 後から同一IP:portでprotocol moduleだけ違うサービスを追加した場合、 > 新たに子プロセスを作るのではなく、既存の同一IP:portの子プロセスに > サービスリストを追加してやらなくてはならない・・・ > →コマンドを受け付ける親プロセスから、たくさんの子プロセス達へ > 　プロセス間通信で情報送ってあげなきゃいけない。 > 　→一番簡単なのはパイプかな。 > 　　→パイプだとファイルディスクリプタ数の上限の制限受けるな > > と連想して、このメール思い出しましたｗ > > パイプ以外に方法あるかなぁ。共有メモリでデータ共有して、 > シグナルかメッセージで通知する？ > そもそもプロセス間通信しなくてすむ方法がある？(←たぶん無い) > > どの方式が一番いいかなぁ。 > >> -- >> TATEISHI Katsuyuki > > >