2023/08/26

t6o_o6t.icon

Socket再実装

Socketは何層？

TCPとUDPを利用するためのインターフェースだったと思う

gnu のソースコードを読む

netcat読み読み

まず、ソースファイルを落としてくる

$ wget ...

URLは、以下から取ってくること

解凍

$ tar -xf netcat-0.7.1.tar.gz

ディレクトリを探索

netcat-0.7.1/lib

netcat-0.7.1/contrib

netcat-0.7.1/src

これっぽい

socketに依存している

注意

Visual Studio Codeの設定変更を推奨.

何について知りたい？

ncが、通信を行う流れを知りたい

→ socketの利用を流れで追っていくと良さそう

流れを知る前に、方法を考える

1. socket通信を行っている箇所を一通り見る

2. mainを通読

一番最初に来るsocket通信を把握する

フォーマットがちょっと適当

VSCodeで一度整形するとインデントが直感的になる

買おうかな

mainの流れは読めた

コマンドライン処理

オプションを見て、対応するフラグを立てる。

重複するフラグなどは、nc_printにEXITフラグを添えて出力

nc_printはexitする

socketへの引数のセット

入力値を、実際にcore.cのAPI呼び出しに使うための構造体に、memcpyを使ってセットしていく

core_listen、core_conect、core_readwrite呼び出し

Listenモード、Tunnelモードの場合は、core_listen

Listen | Tunnelであることを、CONNECTよりモード値が大きいという条件で表現していることに注意

Listenの場合

core_readwriteする

中身は読んでいないが、何かを入力として受けとり、出力するためのものだろうか

これは主にサーバーに用いられるモード

制御が返ってきたら、Listenモードの処理は終わりである

Tunnelの場合についてはよく読んでいない

Tunnelモードを知らないので、読んでも仕方がない

Connectモードの場合は、core_connect

Listenモードがサーバーに用いられることが多いので、反対にConnectモードはクライアントに用いられる

今回読みたかったのはConnectモード

core_connectを呼び出している

それ以上は読まなかった（ソケット呼び出しが把握できれば良かったから）

そして、接続に成功したらcore_readwriteを呼び出す

サーバー特有の処理はcore_listenにありそう

具体的には、サーバーソケットをbindして、接続要求が来るまでlistenすること

クライアントソケットを発行したら、あとは通信先とcore_readwriteで通信するだけだから..

対照的に、クライアント特有の処理 = connect は core_connectにある