新規記事投稿

フォロー記事投稿

記事のキャンセル

4月22日に、take-winさんは書きました。

＞いろいろのご不満は
＞私の読解能力のなさと表現能力のなさのによるものです。
＞ストレスを起こさせてすみません。

ストレスってことはなくて、投稿の仕方がわるかったかな〜と、
考えてました。

別段おかしくないですかね？

＞って書かれている　「その後暇を見て」　の部分
＞
＞私にとっては「コンピュータは暇だらけ」だと思っていました。
＞（実際はどうか知りませんけど）

実際は単体だと暇だらけで正解でしょう。

＞さっさとやりとりしてお互いが見えるようにしろよ！

そうなんですけど、
便利差と快適差ってのは必ずしも共存しないってことですね〜。
便利（簡単？）にすると、速度は犠牲になるものです・・・。

＞という先入観が強くはびこっていまして
＞２１日のＡｋｉｔａｋａ　ＨＯＳＯＭＩさんご指摘のように
＞タイマーが掛かっていると言うことを無視したようになったのだと思います。

よくやっちゃうんですよね〜、これって・・・。


＞なぜタイマーを掛ける（必要がある）のでしょうか？
＞起動の時、さっさとチェックして、
＞どこかその情報を保持しておけばよいのに・・・

ブラウズのやり方が結構ごちゃごちゃしているようなので、
起動時にチェックするってのが結構重たくなるようなので・・・・。

まずブラウズマスタってのがいるっていってますけどこれが曲者で、
これの場所がわからないのでブロードキャストで、
ネットワーク上の全パソコンにパケットをだします。

そして全パソコンからの返事を待つと思うのですが・・・・。
この待つというのですでにタイマーが必要になりますね・・・・。
（応答するといっても全部だとトラフィックがやばくなるので一部でしょうけど。）

しかも、ブラウズマスターは一個所とは限らないので、
全ホストに行き届いたと確信できるだけのタイマーが必要になります。
（この時間は当然、大規模？なネットワークを想定してないといけないので長いです。）

ブラウズマスタがわかれば、やっと通信でホストの情報をもらえます。
（各グループごとのブラウズマスタと通信ですね。）

で、ここでも一斉に全部のブラウズマスタと通信してると、
大規模ネットワークだとトラフィックがおおごとになります。
（だから通信に順序をつけて、タイマー間隔でちょくちょくとなります。）

とかっていうのが、私個人の理解した範囲の理由ですね〜。

＞だから、わざわざ
＞「タイマーを掛けたり」「その後暇を見たり」しなくても
＞３台２組ぐらいの認識なんかすぐ出来てしまう
＞というのが、素人考えなのですけど・・・？

そのネットワークのみを前提にすれば一瞬でしょうね〜。

でもサービスプロトコル自体の仕様は、
ある程度の規模のネットワークを想定してやらないと、
問題が山積みになって、「使えん！」ってことになります。
んで色々設定があると、難しいってことで利用されません。

そこらのバランスの問題なのでしょう。

＞互いの認識は、たとえ、数十台数組でもすぐ出来る？

１、２０台は大丈夫でしょうけど、
それ以上を構成する時が難しくなるでしょうね。
（１台増えただけでトラフィックが大幅に変わる仕様になりそうです。）

＞それとも、何百何千台が繋がること
＞（こうなるといくら早いと言っても、
＞人間の受認範囲を超えるぐらい時間が掛かるだろうと私は予想します）
＞も予想して作ってあるのでしょうか？

基本が企業向けで開発（でないと儲からんですよ。）してるでしょうから、
１，２００台程度は想定してるでしょうけど〜。

実際はネットワークの構造で、快適さや問題発生率が大きく変わりますからね〜。
時間がかかるというか、トラフィック（ブラウズマスタへのパケット集中など）
が問題になりそうなので構成を考えないとね〜。

レスポンスの遅いネットワークは、使い勝手が悪いでしょう？
（まあ問題もでるでしょうし・・・。）

というのが私の意見です〜。