この記事について

Ruby3.x にて使用可能な FiberScheduler#address_resolveを自前実装している。

このメソッドが返す値がRuby言語の中でどのように使用されるのかを確認したい。

`FiberScheduler#address_resolve`について

以下の通り。

調査内容

自分が実装するスケジューラにおいて、FiberScheduler#address_resolveが、["1.1.1.1"]を返すように実装してみた。

class AsyncScheduler
  def address_resolve
    ["1.1.1.1"]
  end
end

すると、このスケジューラを利用したSocket.getaddrinfo("www.google.com", 443)は、

Fiber.set_scheduler AsyncScheduler.new
Fiber.schedule do
  Socket.getaddrinfo("www.google.com", 443) ## この箇所
end

以下の値を返すようになった。

[
  ["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 1, 6],
  ["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 2, 17],
  ["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 3, 0]
]

以下2点を知りたい。

2, 1, 6, 2, 2, 17, 2, 3, 0は何を意味するのか？
Ruby内部のどういった処理によりこれらの３つの値が返っているのか？

調査(1) `2, 1, 6`, `2, 2, 17`, `2, 3, 0`は何を意味するのか？

singleton method Socket.getaddrinfo
アドレス情報とは7つの要素からなる次の形の配列です。

第0要素 - アドレスファミリー (String)
第1要素 - ポート番号 (Integer)
第2要素 - ホスト名 (String)
第3要素 - アドレス (String)
第4要素 - アドレスファミリーに対応する Integer
第5要素 - ソケットタイプに対応する Integer
第6要素 - プロトコルに対応する Integer
https://docs.ruby-lang.org/ja/3.1/method/Socket/s/getaddrinfo.html

つまり、

	address family	socket type	protocol
`2, 1, 6`	`AF_INET`(IPv4)	`SOCK_STREAM`	`IPPROTO_TCP`
`2, 2, 17`	`AF_INET`(IPv4)	`SOCK_DGRAM`	`IPPROTO_UDP`
`2, 3, 0`	`AF_INET`(IPv4)	`SOCK_RAW`	`IPPROTO_IP`

Socket::Constants

https://docs.ruby-lang.org/ja/3.1/class/Socket.html

Socket::Constants::AF_INET = 2
Socket::Constants::SOCK_STREAM = 1
Socket::Constants::SOCK_DGRAM = 2
Socket::Constants::SOCK_RAW = 3
Socket::Constants::IPPROTO_IP = 0
Socket::IPPROTO_TCP = 6
Socket::Constants::IPPROTO_UDP = 17

なお、SOCK_RAWの説明は以下である。

SOCK_RAW
内部ネットワーク・プロトコルおよびインターフェースへのアクセスを提供します。このタイプのソケットは、root ユーザー権限を持つユーザー、または CAP_NUMA_ATTACH 機能を持つ非 root ユーザーのみが使用できます。 (非 root ロー・ソケット・アクセスの場合、 chuser コマンドは CAP_PROPAGATEとともに CAP_NUMA_ATTACH 機能を割り当てます。詳しくは、 chuser コマンドを参照してください。)

ロー・ソケットを使用すると、アプリケーションは下位レベルの通信プロトコルに直接アクセスできます。ロー・ソケットは、通常のインターフェースを介して直接アクセスできないプロトコル機能を利用したい場合や、既存の低レベル・プロトコルの上に新しいプロトコルを構築したい場合に、上級者を対象としています。

ロー・ソケットは通常、データグラム指向ですが、正確な特性は、プロトコルによって提供されるインターフェースによって異なります。
https://www.ibm.com/docs/ja/aix/7.3?topic=protocols-socket-types

調査(2) Ruby内部のどういった処理によりこれらの３つの値が返っているのか？

https://github.com/ruby/ruby を読む。

折角なので、手元にRubyのソースコードを落としてきて、lldbでブレイクポイントを仕掛けてみる。

に従う。

ruby_repo/test.rb

require 'socket'
require '/Users/daiki-kudo/repos/nonblocking-resolv/lib/nonblocking/resolv'
require '/Users/daiki-kudo/repos/async_scheduler/lib/async_scheduler'

scheduler = AsyncScheduler::Scheduler.new
Fiber.set_scheduler scheduler
x = nil
Fiber.schedule do
  x = Socket.getaddrinfo("www.google.com", 443) ## この箇所
end
scheduler.close
print x

$make lldb-rubyで実行する。
($make lldbでは、実行不可だった。外部gemが使用できないとどこかで読んだ記憶がある。)

$ make runruby
RUBY_ON_BUG='gdb -x ../.gdbinit -p' ./miniruby -I../lib -I. -I.ext/common  ../tool/runruby.rb --extout=.ext  -- --disable-gems  ../test.rb 
[["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 1, 6],
 ["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 2, 17],
 ["AF_INET", 443, "1.1.1.1", "1.1.1.1", 2, 3, 0]]%

さて、とりあえず、FiberScheduler#address_resolveを呼び出しているCレイヤーの scheduler.c#rb_fiber_scheduler_address_resolveにブレイクポイントを設置する。ここで、コールスタックを見て、どのような順番でメソッド呼び出しがされているかを調べる。

$ make lldb-ruby

(lldb) br set --name rb_fiber_scheduler_address_resolve
Breakpoint 1: where = ruby`rb_fiber_scheduler_address_resolve + 22 at scheduler.c:673:25, address = 0x00000001001c2746

(lldb) r
Process 32213 launched: '/Users/daiki-kudo/repos/ruby/build/ruby' (x86_64)
Process 32213 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001001c2746 ruby`rb_fiber_scheduler_address_resolve(scheduler=4326338320, hostname=4376285200) at scheduler.c:673:25
   670 	VALUE
   671 	rb_fiber_scheduler_address_resolve(VALUE scheduler, VALUE hostname)
   672 	{
-> 673 	    VALUE arguments[] = {
   674 	        hostname
   675 	    };
   676 	

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001001c2746 ruby`rb_fiber_scheduler_address_resolve(scheduler=4326338320, hostname=4376285200) at scheduler.c:673:25
    frame #1: 0x0000000104c8df66 socket.bundle`rsock_getaddrinfo [inlined] rb_scheduler_getaddrinfo(scheduler=<unavailable>, host=4376285200, service=<unavailable>, hints=0x0000000104c1fa70, res=<unavailable>) at raddrinfo.c:478:26
    frame #2: 0x0000000104c8df51 socket.bundle`rsock_getaddrinfo(host=4376285200, port=887, hints=0x0000000104c1fa70, socktype_hack=0) at raddrinfo.c:545:21
    frame #3: 0x0000000104c85c94 socket.bundle`sock_s_getaddrinfo(argc=<unavailable>, argv=<unavailable>, _=<unavailable>) at socket.c:1186:11
    frame #4: 0x0000000100255c64 ruby`vm_call_cfunc_with_frame_(ec=0x0000000104e05ed0, reg_cfp=0x0000000104c3ff90, calling=<unavailable>, argc=2, argv=0x0000000104c20038, stack_bottom=0x0000000104c20030) at vm_insnhelper.c:3468:11
    frame #5: 0x000000010023a431 ruby`vm_exec_core [inlined] vm_sendish(ec=0x0000000104e05ed0, reg_cfp=<unavailable>, cd=<unavailable>, block_handler=0, method_explorer=mexp_search_method) at vm_insnhelper.c:5546:15
    frame #6: 0x000000010023a374 ruby`vm_exec_core(ec=0x0000000104e05ed0) at insns.def:835:11
    frame #7: 0x0000000100236b92 ruby`rb_vm_exec(ec=0x0000000104e05ed0) at vm.c:2406:22
    frame #8: 0x000000010024ab7f ruby`vm_invoke_proc [inlined] invoke_block(ec=0x0000000104e05ed0, iseq=0x0000000101e04578, self=4301835640, captured=<unavailable>, cref=0x0000000000000000, type=<unavailable>, opt_pc=<unavailable>) at vm.c:1441:12
    frame #9: 0x000000010024aa7e ruby`vm_invoke_proc [inlined] invoke_iseq_block_from_c(ec=0x0000000104e05ed0, captured=<unavailable>, self=4301835640, argc=<unavailable>, argv=<unavailable>, kw_splat=<unavailable>, passed_block_handler=<unavailable>, cref=0x0000000000000000, is_lambda=<unavailable>, me=0x0000000000000000) at vm.c:1511:16
    frame #10: 0x000000010024a91f ruby`vm_invoke_proc [inlined] invoke_block_from_c_proc(ec=<unavailable>, proc=<unavailable>, self=<unavailable>, argc=<unavailable>, argv=<unavailable>, kw_splat=<unavailable>, passed_block_handler=<unavailable>, is_lambda=<unavailable>, me=0x0000000000000000) at vm.c:1609:16
    frame #11: 0x000000010024a7fd ruby`vm_invoke_proc(ec=0x0000000104e05ed0, proc=<unavailable>, self=4301835640, argc=<unavailable>, argv=<unavailable>, kw_splat=<unavailable>, passed_block_handler=0) at vm.c:1639:12
    frame #12: 0x000000010024a79a ruby`rb_vm_invoke_proc(ec=<unavailable>, proc=<unavailable>, argc=<unavailable>, argv=<unavailable>, kw_splat=<unavailable>, passed_block_handler=<unavailable>) at vm.c:1660:16
    frame #13: 0x0000000100078d20 ruby`rb_fiber_start(fiber=0x0000000104e05e80) at cont.c:2525:23
    frame #14: 0x000000010007b8c1 ruby`fiber_entry(from=<unavailable>, to=<unavailable>) at cont.c:843:5

つまり、コールスタックは上から順に

scheduler.c:673 #rb_fiber_scheduler_address_resolve
raddrinfo.c:478 #rb_scheduler_getaddrinfo
raddrinfo.c:545 #rsock_getaddrinfo
socket.c:1186 #sock_s_getaddrinfo

ここで、raddrinfo.c#rb_scheduler_getaddrinfo を抜粋すると、以下。
FiberScheduler#address_resolve から得られたIPアドレスの配列(今回は ["1.1.1.1"])に対してループを周している。
それぞれについて、#numeric_getaddrinfo を呼び出して得られた addrinfoのLinkedListを、同じくLinkedListである(*res)->aiの末尾にくっつけている。

ext/socket/addrinfo.h

static int
rb_scheduler_getaddrinfo(VALUE scheduler, VALUE host, const char *service,
    const struct addrinfo *hints, struct rb_addrinfo **res)
{
    long i, len;
    struct addrinfo *ai, *ai_tail = NULL;

    // FiberScheduler#address_resolve から得られたIPアドレスの配列
    ip_addresses_array = rb_fiber_scheduler_address_resolve(scheduler, host);
    len = RARRAY_LEN(ip_addresses_array);

    for(i=0; i<len; i++) {
        ip_address = rb_ary_entry(ip_addresses_array, i);
        hostp = host_str(ip_address, _hbuf, sizeof(_hbuf), &_additional_flags);

        // ai には、address_info構造体のLinkedListの先頭が代入される。
        // 後述のように、このLinkedListは、SOCK_STREAM, SOCK_DGRAM, SOCK_RAWに対応する３つの要素を持つ。
        error = numeric_getaddrinfo(hostp, service, hints, &ai);

        if (!res_allocated) {
            res_allocated = 1;
            *res = (struct rb_addrinfo *)xmalloc(sizeof(struct rb_addrinfo));
            (*res)->allocated_by_malloc = 1;
            (*res)->ai = ai; // res に address_info構造体のLinkedListの先頭 を代入
            ai_tail = ai;
        } else {
            while (ai_tail->ai_next) {
                ai_tail = ai_tail->ai_next;
            }
            ai_tail->ai_next = ai;　// LinkedListの末尾に要素を追加
            ai_tail = ai;
        }
    }

addrinfo構造体の型

ext/socket/addrinfo.h

struct addrinfo {
	int	ai_flags;	/* AI_PASSIVE, AI_CANONNAME */
	int	ai_family;	/* PF_xxx */
	int	ai_socktype;	/* SOCK_xxx */
	int	ai_protocol;	/* 0 or IPPROTO_xxx for IPv4 and IPv6 */
	size_t	ai_addrlen;	/* length of ai_addr */
	char	*ai_canonname;	/* canonical name for hostname */
	struct sockaddr *ai_addr;	/* binary address */
	struct addrinfo *ai_next;	/* next structure in linked list */
};

raddrinfo.c#numeric_getaddrinfoを抜粋すると以下。
確かに、SOCK_STREAM, SOCK_DGRAM, SOCK_RAWの3種類がlistとして定義されており、ループを回して、これらに対応するaddress_info構造体からなるLinkedListがaiに代入されている。

ext/socket/raddrinfo.c

static int
numeric_getaddrinfo(const char *node, const char *service,
        const struct addrinfo *hints,
        struct addrinfo **res)
{
        static const struct {
            int socktype;
            int protocol;
        } list[] = {
            { SOCK_STREAM, IPPROTO_TCP }, // ここ!!!
            { SOCK_DGRAM, IPPROTO_UDP },
            { SOCK_RAW, 0 }
        };

        for (i = numberof(list)-1; 0 <= i; i--) {
            if ((hint_socktype == 0 || hint_socktype == list[i].socktype) &&
                (hint_protocol == 0 || list[i].protocol == 0 || hint_protocol == list[i].protocol)) {
                // ai  は、LinkedListの先頭のNode
                // ai0 は、今から新しく先頭に挿入するNode
                struct addrinfo *ai0 = xcalloc(1, sizeof(struct addrinfo));                struct sockaddr_in *sa = xmalloc(sizeof(struct sockaddr_in));
                INIT_SOCKADDR_IN(sa, sizeof(struct sockaddr_in));
                memcpy(&sa->sin_addr, ipv4addr, sizeof(ipv4addr));
                sa->sin_port = htons(port);
                ai0->ai_family = PF_INET;
                ai0->ai_socktype = list[i].socktype;
                ai0->ai_protocol = hint_protocol ? hint_protocol : list[i].protocol;
                ai0->ai_addrlen = sizeof(struct sockaddr_in);
                ai0->ai_addr = (struct sockaddr *)sa;
                ai0->ai_canonname = NULL;
                // ai0を先頭に挿入
                ai0->ai_next = ai;
                ai = ai0;
            }
        }

        if (ai) {
            *res = ai;
            return 0;
        }
}