アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
サーバ・クライアントのアクセス速度の対称性 (スコア:2, すばらしい洞察)
今までの常識で考えると、サーバ側には大容量の回線を用意し、多数の(ナローバンドな)クライアントからのリクエストに耐えるという設計にするのでし
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1, 参考になる)
また、Webアプリなんかだと、P2Pに向かないように思えますが、そこいらはいかがでしょうか?
・データのトランザクションはどう保障し、分散効果はどのくらい出ますか?
・アプリのアルゴリズムの同一性をどのように保障しますか?
・データの盗聴対策は?
くらいは考えないと、電波に見えてしまいますよ^^;;
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1)
おっと失礼。よくよく考えてみたら、この件では特に
・クライアントからアクセスコードを入力(数十バイト?)
・サーバから結果を返答
というシステムだから、データ量だけ考えると、実は大したことなさそう。見積もるべき(思案すべき)はデータ転送量ではなく、むしろページビューによるサーバ側負荷だったのか。
>・データのトランザクションはどう保障し、分散効果はどのくらい出ますか?
>・アプリのアルゴリズムの同一性をどのように保障しますか?
>・データの盗聴対策は?
P2P技術が進歩し、こういう問題点を考えねばならなくなるような時代がくることを切に願うばかりです。
# ……で、その問題点の解決策については、
# 当方あいにく持ち合わせておりません。教えてエライ人。
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1, 参考になる)
はやくWebのセッションを開放してくれるからありがたいことが多いな。
Webサーバのプロセス数は有限のリソースですからねぇ。。
#ストリーム系は話が別でしょうね。
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:0)
まだコンテンツもi-mode向けの軽いものではなく、パケ死することも
意識していない人が多かったのか、大きいコンテンツに9600b/sで
アクセスする人がApacheのプロセスを占めて、なかなか開放して
くれないためにアクセスしにくい状態に。