史上最悪のデスペナ さんが書きました:質問をいっぺんに出せたらいいのですが現在進行形で勉強中なので、そういえばこれも、というのがちょくちょく出てきますがお許しください。
個人的には,書籍を買って一度きっちり勉強した方がよい気がします。
私はBerkeley SocketではなくWinSockしか使ったことがありませんし,勉強したのもWinSockの方になりますが……。
私がWinSockについて勉強したのは,古い本ですが,
WinSock 2.0 プログラミング―Window Socket APIによるネットワークプログラミングのすべてになります。
同書の
改訂第2版もありますが,Amazonのマーケットプレイスは現在中古品が10,500円からとぼったくり価格なのでお薦めできません。
史上最悪のデスペナ さんが書きました:
普通の状態では、readやrecvfromはデータが受信できるまでブロッキングします。
これは、Aというソケットにα、βという順にデータが来た場合αを受信し終わるまでブロックしてβが受信できないようにするのでしょうが、受信できなかったβはその後送信側が何のアクションを起こさなくても自動的に受信者側に受信されるのでしょうか?
ブロッキングというのは,その動作を終了するまで
スレッドの実行をブロックするのです。
なので,UIスレッドでrecvやrecvfromを使うと,UIが固まることになります。
UDPパケットβについては,受信側ドライバのバッファに十分な空き容量があれば,そこに保持されるでしょう。
空き容量がなければ,破棄されますが,UDPでのそれらの制御はアプリケーション層の責務です。
史上最悪のデスペナ さんが書きました:また、ソケット一つ一つにポートを振り分けていますが振り分けなくてもいいのでしょうか?MMOに活用するとなると、沢山のソケットとポートが必要になる気がするのですが。
UDPの場合ソケット1つで処理できます。
# recvfromの引数で,通信先のIPアドレスが取得できます。
TCPの場合,listenするソケットは一つでポートも一つですが,acceptでは複数のソケットが生成され,それぞれにポートが割り振られます。