- - PR -
ASP.NETでの閲覧者情報
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-07-24 04:36
技術論に話が行ってますが、 インフラの拡張とかはすでに望めないのでしょうか？ 回線の増強や、負荷分散装置の導入など。 あるいは、最近聞かなくなりましたが、 Akamaiなどのキャッシュサービスの利用とかは？ | ||||||||||||||||||||||||
|
投稿日時: 2005-07-24 10:14
インフラの拡張は全く考えていない訳ではありませんが、
これはあくまでも最後になります。 というのは、DBなどでもパフォーマンスチューニングを行う場合、 最初に行うのはアプリケーションのSQLのチューニングなどを行い、 更にはDBサーバ自体の設定、それでも駄目ならインフラを拡張します。 同様に、まずはアプリケーション側でトラフィックを減少させ、 それでも駄目ならインフラ拡張をする予定です。 | ||||||||||||||||||||||||
|
投稿日時: 2005-07-24 22:04
あれ？そうでした？クライアント側は、投げたリクエストにレスポンスがあるかどうかは、タイムアウトすることによって解りますが、サーバー側は投げた情報すべてがクライアントに正確に届いたかどうかは、解らないんじゃ？TCP/IP で、再送などの手順はとれますけど。UDP とごっちゃにしていますか？ ↑ なので、Tomcat では例外があがってくるというのに、「あれ？そうだっけ？」と疑問に思っていたのですけど？？？ _________________ | ||||||||||||||||||||||||
|
投稿日時: 2005-07-24 22:09
具体的に何を送るのか明らかにされていないので、危険なことがあることを警告するのは、おかしいことでしょうか。 単に、ソフトウェアの配布で、ファイルサーバに対する負荷の軽減が目的であるだけなら、ジャックされたところで危険はないでしょう。 何らかの情報が入ったファイルであるなら、その情報を隠蔽したい人のところへ持って行かれる可能性は否定できないと思います。もっとも、そういうものではないようですが。 _________________ | ||||||||||||||||||||||||
|
投稿日時: 2005-07-24 22:27
一郎さんが ISAPI を出しているし、私も先の投稿でそのページを出しているのですが、それにふれられていないのはなぜでしょう？ また、これで３度目ですが、ノータッチデプロイメント、IE で Windows アプリケーションをホストする方法についてキーワード、また前回の投稿では参考ページを出していますが、それにふれられていないのはなぜでしょう？
でも、アクセス禁止のフィルタから漏れたプロクシを使っている人の間では、そういうことになるわけですよね？そして、プロクシをすべてリストアップするのは無理だと思っています。まぁ、IP アドレスは有限なので、できないことではないでしょうけど。でも、１０分もすればダウンロードは終わって、次の人がダウンロードできるんですよね。そして、そのダウンロードしなければならないファイルというのは、そんなに大量にあるのでしょうか？ 考え方の違いと言われればそうなのですが、、、１０分待たなきゃ落としきれないなら、私なら３つなら３つダウンロードウインドウを開きます。そして別の仕事をします。それが禁じられるわけですよね。 １０分程度で片づく仕事なんてそうそう無いですから、仕事の合間合間に３回に分けて、落とさなければならない。そう解った時点で、私なら、ダウンロードすることをすべて止めます。 この基準は３分程度でしょうか。３分なら待ちます。それ以上かかるなら、他のことをします。 もっとも、ダウンロードツールなんてものがありますから、そいつの同時接続数を１にしてダウンロードをさせる、ということも考えますけど。 もっとも、最近は Opera を使っているせいか、そういうツールも使っていない。MSDN のダウンロードをするときは、そういうツールがあるからそれでする。なので、ダウンロードツールも使っていません。私は、ですけど。 _________________ | ||||||||||||||||||||||||
|
投稿日時: 2005-07-25 00:14
携帯の着メロなどのダウンロードって
「この画面でダウンロードボタンを押したら以降のキャンセルは一切認めません。 通信エラーでもダメです。電波のいいところで充電のいっぱいあるときに行ってください。」 なんて当然のように出ますよね。初めて見たときは目からうろこでした。 これがありならIE限定とかJavaScript必須で文句言ってられないなあなんて思ったり。 こんなような例を出しつつダウンロード完了、未完に限らず10分は再ダウンロード不可 なんてのはいかがでしょうか？ | ||||||||||||||||||||||||
|
投稿日時: 2005-07-25 07:26
Jitta氏
まず、私を含む開発メンバーの中でISAPIを詳しく知ってる人間が居ないので、 そう簡単に検証などして結果などを報告できません。 また、これ以外には手段はないものか？とも考えています。 ノータッチデプロイメントでのWindowsアプリをホストする件ですが、 今回、あくまでも普通のWebアプリケーションですので対象外です。
プロキシの件は何度も言っていますが、そういった仕様です。 使うなと明言している以上、使った場合のユーザの不利益まで考えるつもりは ありません。 ダウンロードするファイルは仕事をする人によりますが、 プロジェクト単位（1プロジェクト5〜30人）で、毎日ファイルを落とす事になります。 このプロジェクト単位でも異なりますが、1日最大で1000個近くのファイルを 落とすプロジェクトもあります。 考え方の違いの件ですが、これはまさしくだと思います。 先程も書いたように1プロジェクトで最大1000近くのファイルを落とす場合が ありますが、基本的にファイルは1つずつ順番に使っていくことになりますので、 1人が仕事をする上で同時に複数のファイルは必要無いのです。 ところが、殆どの人間が朝、出社してくるとダウンロードツールなどを使い、 今日1日必要なファイルを一気にダウンロードしようとします。 この時点でサーバ負荷が高くなり、ダウンまではしませんが・・・という状態です。 ちなみに、このファイルが無いと仕事になりません。 ただし、仕事をする上で必要なのは1ファイルあれば良いので、 1ファイル落とした後、仕事を進め、その作業が終わったら次のファイルを開いて 作業をするという形になります。 | ||||||||||||||||||||||||
|
投稿日時: 2005-07-25 12:10
どもです。がるです。
いくつかに軽く突っ込みを入れつつ本題を。 先に突っ込みを入れると面倒なので、本題から。
あー…。とりあえず上記をみてうなずいた皆様。 とりあえずRFCくらいは読んでから発言を続けませんか？ # DAIさんは、発言を見るに「内省して学習する意欲がない」と思われるので # もはやなにも言うつもりはありませんが。
このJittaさんの発言でほぼ「全て」ではあるのですが。 TCP/IPは、受け取り手が「欠けているパケット」を必要に応じて 「サーバ側に再送信を要求するための」手順と手法が確立されています。 これが一般に「UDPと違ってTCPは確実性がある」といわれる所以です。 ちなみに、この機能のためには当然のことながら ・エラーであることを認識できるためのなんらか ・エラーが発生した場合に「再送要求」を依頼するなんらか が最低限必要となります(実際にはもうちょっと色々と)。 で。HTTPに、とりわけ「HTTPのクライアント側の実装」に、 そういった再送手順が存在しますか？ HTTPの仕様はRFCにきれいにまとまってます(いやあれがきれいか どうかは主観にも拠るのでしょうが、そこは敬意を表してって ことで :-P )。 HTTPで規定されているのは ・クライアント側(ブラウザ)からサーバに送られるREQUEST ・サーバがREQUESTに応じてクライアント側に返すRESPONCE だけです。 「今」知らないことがあるのは当然です。でも、知らないことが わかったなら、勉強くらいしませんか？ ーー 以降、軽く突っ込みを。
んっと。こういう認識でWeb 上でのサービスを組み立てられるのは 個人的には「とても怖いなぁ」と。 DAIさんとクライアントさんの視点から立てば上記はまぁ本音なの でしょうが、実際には「改竄をせずに踏み台として利用する」方法 その他、いくつかの脅威が想像つきます。 もちろん「データが盗まれるのみで改竄されない」ってのも、 場合によっては十分に問題です(そのサーバ、もしくは"そのサーバから ネットワーク的に手を伸ばせるコンピュータ"上に重要なデータが あるか否かによるのですが)。
んっと。 ・HTTPで出来る ・でも.NETじゃ出来ない であれば、「じゃぁ.NETで"出来ない理由を迂回して"なんとか HTTPを直接叩いて」という方向性が成り立ちうるのですが。 そもそも根底となっているプロトコルのHTTPで出来ないことは、 その上に載っているものでは、どうあがいても「厳密には」 無理です。 っていうか、.NETって普通に「HTTPを実装」しているので、 つまりは「HTTPの仕様に」拠っていると思うのですが？ ましてや、対になるクライアントは「普通にブラウザ」ですし。 これが ・HTTP上に「新しいプロトコル」を設立 ・そのためにクライアントも新しいプロトコル用のものを使用 であれば、もちろん「HTTP上で実装できていない機能を実装する」 事もある程度可能ではあるのですが。
あー。携帯サイトもそこそこ作ってきましたが。あれって 結構苦肉の策なんですよねぇ(苦笑 ただ、携帯の、特に公式コンテンツの有利なことは「確実に １個人が特定できる」ので。 もしダウンロードで失敗しても、それなりにフォロー処理は 盛り込めるです。割合に簡単に。 ただ、結局のところ「HTTPの投げっぱなし状態」が結構危なくて。 例えば、ユーザが 1.地下鉄などの電波状態の悪いところでダウンロード開始 2.即効で電波が切れる 3.電波がつながったところで再ダウンロード開始 4.２に戻る なんて事をやってくれると、サーバとしては「毎回、全部を ネットワークに垂れ流す」ことになるので、回線を含め、 結構困ったことになるです(苦笑 なので、微妙に脅迫めいた文章で一瞬手を止めるわけです(笑 以上。厳しい発言も多々あるかとは思いますが。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。