どうやらgetaddinfoの関数ではねられているらしいことが分かる。
vlcではvlc_getaddrinfoが用意されており、その先、vlc内のgetaddrinfoにつながると思いきや、libcのposixのgetaddrinfoに飛んでいることが分かった。
libcのposixはウブであるため、socktypeとしてSOCK_DCCPを知らない。よってEAI_SOCKTYPEという「そんなソケットタイプしらねーよ＾＾」エラー(-7)を返してくれる。
クライアント側のDCCPがgetaddrinfoをどのように回避しているのか調べると、当初はudpと偽ってgetaddrinfoして変換し、socketを作る段階になって、protocol ?: ptr->ai_protocolのように定義したprotocol（ココではDCCP）を優先するようにしているようだ。
以上の作業で、エラーが出ずに実行できるようになったが、VLC上でまともにDCCPサーバが立っている気配がない。
調べようとしても、netstatにはdccpの状態なぞ出てこないので、tshark(旧tethereal)とDCCP – LinuxNetのrubyのコードからクライアントのみ、サーバのみのコードを生成して検証している状態である。
ちなみに、DCCPクライアントとしては動作するはずのVLCであるが、まともに動作している気配がない。なぜかipv6アドレスの::1、port 80にアクセスしようとする。書き方が悪いのだろうか…