プログラマ専用SNS ミクプラ

Geekなページで
addr.sin_addr.S_un.S_addr = inet_addr("239.192.1.2");
このｱﾄﾞﾚｽは何を指しているのでしょうか？
一応、問い合わせたのですが

内容によっては、どこのどなたであるかの記述がなく無料メールサービスのメールアドレスだけが記述してある場合は、返信を躊躇する場合もあります。
また、web内コンテンツの変更をもって返答とさせていただいたり、返答を行なわない事もございます。

と問い合わせフォームにありまして、～大学の○○です、とか～社の□□です、とやるのも少しあれだったので書かなかったため、返答いただけなかったのか
お忙しくてまだ目を通してないのか分かりませんが、すぐに知りたいので申し訳ありませんが教えていただけないでしょうか？

予想→サーバーとして使用するPCが接続しているDHCPサーバーのｱﾄﾞﾚｽ

追記：改題しました

史上最悪のデスペナ さんが書きました:Geekなページで
addr.sin_addr.S_un.S_addr = inet_addr("239.192.1.2");
このｱﾄﾞﾚｽは何を指しているのでしょうか？

史上最悪のデスペナ さんが書きました:予想→サーバーとして使用するPCが接続しているDHCPサーバーのｱﾄﾞﾚｽ

UDPマルチキャストについての勉強不足ですね。
224/4はマルチキャスト用のIPアドレスです。
で，239/8がある程度自由に使えるマルチキャスト用のアドレスになります。

で，それぞれのマルチキャスト用のアドレスがマルチキャストのグループになります。
今回の場合は，239.192.1.2というグループになります。
このアドレスは，ソフトウェア側で決定することになります。
# グループなので，マルチキャストに参加する全ての端末が同一アドレスを指定することになります。


30分ほど検索して調べただけの付け焼き刃なので，間違っている可能性がありますが……。
References)
30 Minutes Networking No.SW21
IPv4 - Wikipedia
マルチキャストのアドレッシング
IANA Guidelines for IPv4 Multicast Address Assignments

根本的なことですが、ゲームでマルチキャストすることって無いのでは？
同一LANじゃないとまともに動かないと思いますし。WANだと迷惑以外の何者でも無いです。

YuO さんが書きました:マルチキャストのアドレッシング

このサイトは質問してから探したときに見つけましたが、WANで使うにはどうしたらいいか分かりませんでした。

softya（ソフト屋) さんが書きました:根本的なことですが、ゲームでマルチキャストすることって無いのでは？
同一LANじゃないとまともに動かないと思いますし。WANだと迷惑以外の何者でも無いです。

例えば（作ろうとするMMOの）チャットを例にとりますと
（softya（ソフト屋)さんがMMOされる、またはされたことあるのか存じませんが）
所謂「シャウト」とか「ワールドチャット」とか言われる、チャンネル内またはサーバー内の全員に送る・・・・・と言いますか、読むことの出来る文を送信する場合
マルチキャストであればいっぺんに送信できていいと思ったのです。
ブロードキャストと違い、それ以外の人に迷惑かけませんし・・・・・・・・・・・・と思ったらたまたま同じｱﾄﾞﾚｽ選んだら駄目でしたね・・・・・・・・・

では、基本ユニキャストなのでしょうか？

追記：改題しました

史上最悪のデスペナ さんが書きました:では、基本ユニキャストなのでしょうか？

私はそうだと思っています。

参考　↓
「[netshow]マルチキャストとユニキャストの相違点」
http://support.microsoft.com/kb/291786/ja

なるほど・・・・・・・マルチキャストはMMOのためにあると思ったのですが・・・・・・残念。

質問をいっぺんに出せたらいいのですが現在進行形で勉強中なので、そういえばこれも、というのがちょくちょく出てきますがお許しください。
次の質問は、
Geekなページ：selectを使うで

普通の状態では、readやrecvfromはデータが受信できるまでブロッキングします。

これは、Aというソケットにα、βという順にデータが来た場合αを受信し終わるまでブロックしてβが受信できないようにするのでしょうが、受信できなかったβはその後送信側が何のアクションを起こさなくても自動的に受信者側に受信されるのでしょうか？

また、ソケット一つ一つにポートを振り分けていますが振り分けなくてもいいのでしょうか？MMOに活用するとなると、沢山のソケットとポートが必要になる気がするのですが。

史上最悪のデスペナ さんが書きました:質問をいっぺんに出せたらいいのですが現在進行形で勉強中なので、そういえばこれも、というのがちょくちょく出てきますがお許しください。

個人的には，書籍を買って一度きっちり勉強した方がよい気がします。
私は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では複数のソケットが生成され，それぞれにポートが割り振られます。

YuO さんが書きました:個人的には，書籍を買って一度きっちり勉強した方がよい気がします。

仰るとおりです。今までは極力自分の力で何とかしようとしてきましたが、最近ここでの聞き癖がついてきているようですね＾＾；
諦めるのが早いですし。
まあ、ネット代は親持ちだし固定料金だからいいんですが書籍代は出せる余裕がないです・・・・・・・orz
親に買ってもらうのはなんですし・・・・・・・・
何とか今迄みたいにネットで情報収集しようかと思います。

取り合えず解決にしておきます

とりあえず一通り勉強が終わったと思ったので戻ってまいりました。

YuO さんが書きました:ブロッキングというのは，その動作を終了するまでスレッドの実行をブロックするのです。
なので，UIスレッドでrecvやrecvfromを使うと，UIが固まることになります。

受信データが少なければ人が認識できるほどのラグは存在しないと思うのですがどうなんでしょう？

受信データが多い少ないの問題ではありません．
recvを使うと，受信データが来るまでrecv関数から処理が戻ってこないために，そこでスレッドがストップしちゃうということです．

マルチスレッドについて勉強したのですが
スレッドがストップしちゃう場合、他のスレッドに影響はないのでしょうか？

例えば、
受信スレッドとゲーム関連スレッドに分けた場合
データが来なくて受信スレッドがブロックされていてもその間ゲーム関連スレッドではきちんと処理が行われるのでしょうか？

原則は，あるスレッドの動作が他のスレッドの動作に影響をあたえることはありません．

しかし，同期処理といって，スレッドAが他のスレッドBに対して「俺この変数今から使うから，お前も使いたくなったら俺が使い終わるまで待っててね！」と宣言し，本当にスレッドBがその変数を使おうとすると，スレッドBはスレッドAがその変数を使い終わるまでストップします．

同期処理をサボるとデータがむちゃくちゃになって，プログラムのバグの原因になります．
かと言って，不必要な同期処理をやると，スレッドの並列性が失われて，処理速度が低下する原因になります．

beatle さんが書きました:原則は，あるスレッドの動作が他のスレッドの動作に影響をあたえることはありません．

しかし，同期処理といって，スレッドAが他のスレッドBに対して「俺この変数今から使うから，お前も使いたくなったら俺が使い終わるまで待っててね！」と宣言し，本当にスレッドBがその変数を使おうとすると，スレッドBはスレッドAがその変数を使い終わるまでストップします．

同期処理をサボるとデータがむちゃくちゃになって，プログラムのバグの原因になります．
かと言って，不必要な同期処理をやると，スレッドの並列性が失われて，処理速度が低下する原因になります．

逆に言えば、同じ変数を使わないように、かつ（同じ使い方をされる変数を二つ作るような）無駄なメモリを消費しないようにスレッドを作ればいいんですよね？

史上最悪のデスペナ さんが書きました:逆に言えば、同じ変数を使わないように、かつ（同じ使い方をされる変数を二つ作るような）無駄なメモリを消費しないようにスレッドを作ればいいんですよね？

まあそういうことですが，完全に達成しようとすると不可能です．
なぜなら，まったくメモリを共有しないということは，計算結果の受け渡しが出来ないということです．
それではスレッドの存在価値はほとんどありません．
ということで，有用なスレッドを作る以上は同じ変数を使う場面が出てきますから，同期処理は大切です．

ノンブロッキングで処理できるかも知れない処理をワザワザ制御が難しいスレッドで行うこと自体ナンセンスです。

史上最悪のデスペナ さんが書きました:逆に言えば、同じ変数を使わないように、かつ（同じ使い方をされる変数を二つ作るような）無駄なメモリを消費しないようにスレッドを作ればいいんですよね？

それだとスレッドはメインと何の関わりもないプログラムになってしまいます。何のために通信しているか本末転倒です。

softya（ソフト屋) さんが書きました:ンブロッキングで処理できるかも知れない処理をワザワザ制御が難しいスレッドで行うこと自体ナンセンスです。

beatle さんが書きました:有用なスレッドを作る以上は同じ変数を使う場面が出てきますから，同期処理は大切です．

自称プログラマーのひよこな私はスレッドを使わなくてすむ方法で頑張ろうと思います。

ありがとうございました。完全に解決です