技術詳細とは？ わかりやすく解説

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/05 17:32 UTC 版)

「パイレート・ベイ」の記事における「技術詳細」の解説

当初、パイレート・ベイの4台のLinuxサーバーは、Hypercubeと呼ばれる独自のウェブサーバーを稼働させていた。古いバージョンのHypercubeはオープンソースである。2005年6月1日、パイレート・ベイは、帯域の使用を減らすためにウェブサイトのアップデートを行った。アップデート前には、4台のウェブサーバーそれぞれに、1ミリ秒につき2件のHTTPリクエストがあった。また、このアップデートには、ウェブサイトのフロントエンドをよりユーザーフレンドリーなインタフェースにするという目的もあった。ウェブサイトは現在、動的フロントエンドにLighttpdとPHP、データベースのバックエンドにMySQL、二つの検索システムにSphinx、SQLクエリとPHPセッションのキャッシュにMemcached、静的なコンテンツをキャッシュするためLighttpdのフロントにVarnishを使用している。2008年9月時点では、パイレート・ベイは31台のサーバーからなる。これには、9台の動的ウェブフロント、1台のデータベース、2台の検索エンジン、8台のBitTorrentトラッカーが含まれる。 2007年12月7日、パイレート・ベイは、BitTorrentトラッキングソフトウェアとして、HypercubeからOpentracker（英語版）への移行を完了した。また、HypercubeがサポートしていなかったUDPトラッカープロトコルの使用も可能となった。これにより、複数のサーバーが相互に同期を取るのにUDPマルチキャストを使用できるようになり、同期処理が以前よりも高速にできるようになった。Opentrackerはフリーソフトウェアである。 2008年6月、パイレート・ベイは、スウェーデンの新たな通信傍受法に応じて、サーバーをSSL暗号化に対応させるだろうと発表した。2009年1月19日、IPv6バージョンのOpentrackerを使用し、トラッカーシステムでのIPv6のサポートを開始した。2009年11月17日、パイレート・ベイは、トラッカーサービスを停止した。分散ハッシュテーブル (DHT)、ピア交換（英語版） (PEX)およびマグネットリンクを用いれば、非中央集権的なやり方でピアやコンテンツを見つけることができるので、中央集権的なトラッカーはもはや必要ない、と述べている。 2012年2月20日、パイレート・ベイはFacebookの投稿で、2月29日以降はトレントファイルを提供せず、代わりにマグネットリンクのみを提供するだろう、と発表した。「トレント(ファイル)を持たないことで我々は少し安く済み、また、敵が我々を止めるのが難しくなるだろう」とコメントした。10人未満で共有されているトレントについては、マグネットリンクをサポートしない古いソフトウェアとの互換性を保証するため、トレントファイルが保持されるだろう、とも述べた。

※この「技術詳細」の解説は、「パイレート・ベイ」の解説の一部です。
「技術詳細」を含む「パイレート・ベイ」の記事については、「パイレート・ベイ」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/10/03 22:28 UTC 版)

「Deflate」の記事における「技術詳細」の解説

deflateは、LZ77（実際にはその変種のLZSS）でデータを「文字そのもの」または （一致長, 一致位置） ペアに符号化する。その結果のうち、「文字そのもの」および「一致長」を合わせて一つのハフマン符号で符号化し、「一致位置」を別のハフマン符号で符号化する。deflateのハフマン符号化は、ブロック毎に符号を(再)構築する方式で、ダイナミックハフマン符号（英語: dynamic Huffman coding）と呼んでいる。日本で一般に動的ハフマン符号と呼ばれている適応形ハフマン符号（英語版）とは異なるので注意。

※この「技術詳細」の解説は、「Deflate」の解説の一部です。
「技術詳細」を含む「Deflate」の記事については、「Deflate」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/19 09:45 UTC 版)

「リープカード」の記事における「技術詳細」の解説

リープカードは非接触型ICカード技術である、「RFID」を採用している。ルアス独自のICカードとアイルランド国鉄独自のICカードでは、「MIFARE」が採用されていた。MIFAREのセキュリティ上の懸念から、設計会社であるNXPセミコンダクターズは、より優れた暗号化方式を使用するRFIDカードを開発した。ダブリンバスで使用される改札機（バスドライバー改札機とバス無人改札機）はMIFARE/NXPによって製造され、ルアス停留場と鉄道駅に設置されている簡易改札機もMIFAREによって製造されている。 リープカードはMIFARE DESFire EV1を採用している。以前までは、ダブリン都市圏のRFID切符はMIFARE Ultralight（タイプA（ISO/IEC 14443タイプA））を採用しており、アイルランド国鉄独自のICカードはMIFARE Classic 1kを採用していた。 リープカードの実現費用は、5500万ユーロだったが、2011年12月の発売以来、売上高は2015年4月現在、2億6,300万ユーロに達した。

※この「技術詳細」の解説は、「リープカード」の解説の一部です。
「技術詳細」を含む「リープカード」の記事については、「リープカード」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/28 07:47 UTC 版)

「オープンバッジ」の記事における「技術詳細」の解説

オープンバッジは、学術用途と非学術用途の両方を含む、幅広いデジタルバッジの用途に対応するように設計されている。仕様は、3種類のバッジオブジェクトで構成： アサーション 授与されたバッジ。これには、獲得者個人単位のバッジに関する情報が含まれる。 バッジクラス 特定のバッジが認識する成果に関する情報が含まれる。同じバッジが多くの受賞者に授与される可能性があるため、単一のバッジクラスに対応する多くのアサーションがある。 イシュア バッジを発行した個人、組織などに関する情報。 バージョン1.1以降、オープンバッジには有効なJSON-LDを使用する必要がある。バージョン1.1は拡張機能も追加された。発行者、稼ぎ手、または消費者がバッジに追加された情報を理解できるように、バッジオブジェクトを共同で拡張するための標準形式に従う構造。発行者は、バッジに新しいタイプのメタデータを含めるように拡張機能を定義して公開可能。他の発行者は、同じ拡張子を使用して、相互に認識できる方法で同様の情報を公開できる。 Open APIがExperience APIアクティビティストリームから参照できるように、探索的なプロトタイプドラフトxAPIボキャブラリが定義されている。

※この「技術詳細」の解説は、「オープンバッジ」の解説の一部です。
「技術詳細」を含む「オープンバッジ」の記事については、「オープンバッジ」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2015/12/30 13:44 UTC 版)

「GVfs」の記事における「技術詳細」の解説

GVfsはFUSEを使い、従来の GnomeVFS の代替を意図したものである。アプリケーションがロードするGIO（英語版）をサポートした共有ライブラリと、相互の通信やD-Bus上のGIOモジュールとの通信を行う各種デーモンで構成されるGVFS本体からなる。 2010年12月現在、登録された113のGNOMEコンポーネントのうち107がGIO（英語版）に移植され、GVfsのURIをサポートしている。また、gvfs-mount、gvfs-lessなどGVfsリソースに対して機能するコマンドラインのユーティリティ群もある。

※この「技術詳細」の解説は、「GVfs」の解説の一部です。
「技術詳細」を含む「GVfs」の記事については、「GVfs」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/08 09:58 UTC 版)

「BITNET」の記事における「技術詳細」の解説

BITNETのNJE（ネットワークジョブエントリ）ネットワークプロトコルは、RSCS（英語版）という、VNET（英語版）として知られているIBM内部の巨大なネットワーク用プロトコルであった。BITNETは、当初9600ボーで動作した。やがて、BITNETのプロトコルは非IBMメインフレームのオペレーティングシステムに移植され、特にVAX/VMSでよく使われた。 BITNETでは、FTP・Gopher・World Wide Webが使われるようになる以前は電子メールとLISTSERV（メーリングリスト）がよく使われていた。メーリングリストのためのゲートウェイは、メーリングリストをUsenetで利用可能にした。BITNETも、他のユーザーのためにファイルとメッセージの双方向伝送をサポートした。TRICKLE（英語版）と呼ばれるゲートウェイ・サービスで、ユーザーはインターネットのFTPサーバから、uuencodeでエンコードされ64キロバイトごとに分割された状態でファイルを取得することができた。Interchat Relay Network（一般にはBITNET Relay（英語版）として知られる）は、BITNETのインスタントメッセージング機能であった。BITNETの最初の電子雑誌"VM/COM"は、メイン大学のニュースレターとして始まり、1984年前半に広く普及した。1987年秋にBITNETで始まった2つのニュースレター、"the Electronic Air"と"SCUP Email News"（元"SCUP Bitnet News"）は、現在も発行されている。 非営利・教育用という使用方針により、援助やソフトウェアのバグ・フィックスに関して、IBM自体を含む商業的な団体との情報交換が制限された。

※この「技術詳細」の解説は、「BITNET」の解説の一部です。
「技術詳細」を含む「BITNET」の記事については、「BITNET」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2019/09/09 01:21 UTC 版)

「Key Management Interoperability Protocol」の記事における「技術詳細」の解説

KMIPサーバは暗号鍵、証明書、パスワード等を保存・管理する。技術詳細は公式ページやウィキで公開されている。

※この「技術詳細」の解説は、「Key Management Interoperability Protocol」の解説の一部です。
「技術詳細」を含む「Key Management Interoperability Protocol」の記事については、「Key Management Interoperability Protocol」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/05/15 02:57 UTC 版)

「トレーシング実行時コンパイル」の記事における「技術詳細」の解説

トレーシング実行時コンパイラは実行時に以下のステップを経る：第一に、ループに関するプロファイリング情報を収集する。次にホットループを特定した後、トレーシング実行モードに移行し、そのループを実行するのに用いられたすべての演算を記録する。記録された演算列はトレース（trace）と呼ばれる。その後トレースは最適化され機械語にコンパイルされる。再びそのループが実行される際はオリジナルのコードではなくコンパイル済みのトレースを実行する。 以下で各ステップを詳細に説明する。

※この「技術詳細」の解説は、「トレーシング実行時コンパイル」の解説の一部です。
「技術詳細」を含む「トレーシング実行時コンパイル」の記事については、「トレーシング実行時コンパイル」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/06/25 06:07 UTC 版)

「DOS/360」の記事における「技術詳細」の解説

下記の解説は特に明記がない限りDOS/360に固有のものである。以降のバージョンでは機能が強化されている。 DOS/360はSystem/360のローエンドモデルで動作するように設計されたためメモリ消費量が大きな懸念事項だった。OSの常駐部分であるDOSスーパバイザを生成可能で、そのサイズは5902バイト程度だった。詳細チャート図には各sysgenオプションも必要メモリ容量が記載されており、その多くはわずか100バイト程度だった。最小のシステム構成では1本のメモリパーティションに10KB強のストレージが残され、ユーティリティやコンパイラを動かすには普通は十分な容量だったが、COBOL、PL/I、フルセットのFORTRAN IVなどを走らせるには足りなかった。メモリ容量を可能な限り抑えるためDOSはフルアセンブラで記述された。

※この「技術詳細」の解説は、「DOS/360」の解説の一部です。
「技術詳細」を含む「DOS/360」の記事については、「DOS/360」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/12/27 08:48 UTC 版)

「Spanner (データベース)」の記事における「技術詳細」の解説

上記の通り、Spanner ではデータの一貫性を担保する必要があった。これを実現するために、BigTableとは異なり、Spanner ではタイムスタンプが必ずデータに付与される。このデータ構造はtabletと呼ばれ以下のようなマッピングを持つ： (key:string, timestamp:int64) -> string これらデータはGoogle File Systemの後継であるColossus上に全て保存される。 上記のようにタイムスタンプを用いることで、全てのトランザクション処理のコミットがどの順番で行われたかを管理でき、これによって、一貫性を保証できる（詳細はMultiVersion Concurrency Controlを参照）。 ここで重要となるのは、タイムスタンプを一貫した時刻基準を用いて押し、処理した順番を誤って前後させないことである。しかしながら、Spannerのようにデータが複数のサーバに分散される場合は実現が難しい。全てのサーバを常に、かつ厳密に同時刻に保つことは困難なためである。 これを解決するために、Spannerでは、TrueTime APIを利用して、現在の絶対時刻をある幅TTinterval: [earliest, latest]を持たせて取得する。これは、現在の絶対時刻 t a b s {\displaystyle t_{abs}} が、earliest以上、latest以下であることを保証する。すなわち、Spanner のサーバ群の中で最も早い/遅い時間は、それぞれearliest/latestであり、他の全てのサーバはこの範囲内に収まるということである。このように、時刻ずれのワーストケースが分かっているため、処理の順序関係に不整合がでないようにデータベースの読み書きを制御する事が可能となり、データの一貫性が保たれる。 時刻のずれ量が大きくなるほど、処理をコミットするまでの待ち時間が大きくなり、性能が劣化する。このため、SpannerではGPSや原子時計を利用した正確な時刻基準をマスター・サーバに利用して、できる限りスレーブ・サーバ間のずれを少なくするようにしている。

※この「技術詳細」の解説は、「Spanner (データベース)」の解説の一部です。
「技術詳細」を含む「Spanner (データベース)」の記事については、「Spanner (データベース)」の概要を参照ください。

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/01 05:33 UTC 版)

「PhotoDNA」の記事における「技術詳細」の解説

PhotoDNAは、画像を白黒化し、格子状に分割し、格子の濃淡を数値化することで、ハッシュ（電子署名）を作成し、それによってネット上での再利用を減らすことができる。顔認識技術や画像中の人物・物体の特定をしているわけではなく、画像のハッシュ値と監視団体や企業がすでに違法と認定した画像のデータベースを比較している。PhotoDNAのハッシュの参考データベースを作成している英国のInternet Watch Foundationは、現在、児童の性的搾取の資料として知られている30万件のハッシュを保有している。 PhotoDNA for Videoは、ビデオをキーフレームに分解し、それらのスクリーンショットのハッシュを作成している。PhotoDNAは発見されないように加工された画像と照合することが可能だが、それと同様にPhotoDNA for Videoは、一見無害に見えるビデオに編集され組み込まれた児童の性的搾取に関わるコンテンツを発見することが可能である。また、PhotoDNA for Videoは、1つや複数のキーフレームのハッシュに基づいて、他のビデオに違法なビデオを埋め込まれたものを発見することができる。

※この「技術詳細」の解説は、「PhotoDNA」の解説の一部です。
「技術詳細」を含む「PhotoDNA」の記事については、「PhotoDNA」の概要を参照ください。