今では、主要なソフトウェア構成管理（SCM）システムのほとんどが、社内LAN（ローカル・エリア・ネットワーク）をサポートしています。つまり、 LANを経由して接続されたユーザなら誰でも、まるで自分のデスク上で仕事しているかのように、SCMのリポジトリに透過的にアクセスすることができま す。
しかしながら、低速のWAN（ワイド・エリア・ネットワーク）に対する透過的なサポートにまで拡張できる商用SCMシステムはあまりありません。
ほ とんどのSCMシステムは、LANの高速性と速い応答時間に依存しているためにWANでの使用をサポートしないか、サポートしているとしても十分に透過的 なソリューションは提供していません。典型的には、ローカルユーザはリポジトリに対し最も優遇されたアクセスができるのに対して、リモートユーザはリポジ トリの複製（読み取り専用）を扱わなければいけないか、大量のソースコードに対する統合作業に直面しなければなりません。

しかし、先進的な会社や、それらの会社におけるソフトウェア開発の部署では、急速に分散開発が進んでいます。会社の吸収合併の後には、キーとなる開発チー ムは国内のいたるところに、あるいは世界中に分散していて、会社全体のイントラネットで接 続されているかもしれません。在宅勤務の開発者は、しばしば強力な開発環境を自宅のデスクトップに持ち、ISDN回線またはADSL回線でオフィスと接続 しています。また、いくつかの立ち上がったばかりの会社では、本社をまったく持たず、その代わりに完全にインターネット（これは本質的にはワールドワイド な公共のWANです）を通じた共同作業を行っているものも見られます。

このような組織には、ネットワークを使用したソフトウェア開発が必要です。本稿では、PERFORCE － 高速なSCMシステム － が、会社全体のイントラネットやインターネットなどのWANを使用している環境を取り扱うことができるかを議論します。基本的な主張は、PERFORCE はそのような低速で遅延時間の大きい、長く張り巡らされたネットワークにおいてもその動きが妨げられることはない、ということです。また、このようなネッ トワーク環境での運用において、セキュリティを高めるためのいくつかの点についても述べます。

ネットワーク・パフォーマンスに関する2つの測度は、バンド幅と遅延時間です。バンド幅とは単に、あるコンピュータから次のコンピュータへ1秒あたりどれ ほどのビット数を移動できるかを言います。その範囲は、最近ではモデムを介する場合の14.4Kbps(キロビット/秒)から光ファイバーを介した場合の 100Mbps（メガビット/秒）を超える値となります。遅延時間は、各ビットが一端から次の一端に移るときに発生する遅れです。その範囲は、イーサネッ トにおける1ms以下の値から、インターネットにおける良くて1秒（あるいはそれ以上の何秒か）程度の値です。ネットワークで使用される代表的なネット ワーク物理層における、およその比較を以下の表にまとめました。

LANのパフォーマンス

ネットワーク	バンド幅	遅延時間	コスト
イーサネット	10Mbps	1ms	$
光ファイバー	100Mbps	1ms	$$$

WANのパフォーマンス

ネットワーク	バンド幅	遅延時間	コスト
モデム	28.8Kbps	300ms	$
ISDN	64Kbps	20ms	$$
T1	1Mbps	>1ms	$$$
T3	40Mbps	>1ms	$$$$
ATM	100Mbps	>1ms	$$$$$

LANの世界では、10Mbpsのイーサネットが大半を占めています。これよりも遅い作業環境を、我慢して使用するユーザも少しはいるでしょう。一方 WANにおいては、ほとんどがT1のスピードか、それよりも遅い速度で接続されています。

WANにおける遅延時間は、基盤となるテクノロジと、コンピュータ間の距離によって決定されることに注意してください。ATMネットワークでさえ、ワイヤ の中を通る電気信号や、空間を伝わるマイクロ波のスピードを越えることはできません。 最も速いネットワーク環境においても、ロンドン～カリフォルニア間は少なくとも30msは離れています。実際、長い伝送経路の場合は記憶、転送、スイッチ ングなどの間、パケットを持ちこたえさせる必要があります。そのため、ほとんどのWAN環境での遅延時間は100msか、それ以上になります。

WANの問題点は、長い遅延時間がネットワーク・ファイルシステム（NFS）プロトコルを不調にすることです。このNFSプロトコルは、ほとんどの代表的 なSCMシステムのアーキテクチャの基礎となっています。これらのシステムは、NFSが遠くのディスクをローカルにあるかのように見せてくれるという事実 の上に、ネットワーク透過性を実現しています。実際、いくつかのSCMシステムは（それ自身では）ネットワークをサポートしておらず、ネットワーク・ディ スクへアクセスできることに依存しているだけのものもあります。ネットワーク・ファイルシステム自身は、ネットワーク自身が高速だという仮定のもとに作ら れています。つまり、NFSはローカルディスクを持っているかのように見せかけようとし、NFSプロトコルはネットワークがディスクの（持っている）速さ で応答してくれると仮定しています。ネットワークの応答があまりにも遅すぎると、NFSがダウンします。単純明白です。NFSがダウンすると、SCMシス テムも同じことになります。

NFSによっては（NTにおけるNetBEUIや、4.4BSDにおけるTCP上のNFSなど）、低速度でのWAN環境における動作の問題を克服したもの もあります。しかしこれらもまた、LANより速くデータを送ることはできません。SCMシステムは、ディスクに対する高速なアクセスを当然のことと期待す るアプリケーションです。つまり、SCMシステムはディスクに強く依存した操作（ディレクトリをスキャンしたり、非常に多くのファイルを開いたり）を行い ます。低速のWANにマウントされたリモートディスクは、要求された速さでデータを送ることができません。その結果、SCMシステムのパフォーマンスはお よそ我慢できないものとなります。

市販されている多くのSCMソリューション（ツール）は、その透過性をすべてNFSに依存しており、いずれもWAN環境に対しての普遍的なソリューション をサポートしてないと言えます。いくつかの製品ではリポジトリの複製を作り、複製同士で一方向または両方向の同期をとる機能を提供することでWAN環境を サポートしています。が、これは明らかにLAN環境でのサポートとは異なるものであり、環境構築および運用のための工数（コスト）を別途必要とします。

上で述べたSCMソリューションと同様、PERFORCEはネットワークをサポートするようなアーキテクチャを持っています。しかし、PERFORCEに はネットワーク・パフォーマンスへの依存度を低減させる2つの明確な特徴があります。
その特徴について、以下に示します。

	3.1 ファイルはローカルに、メタデータは中央に
	PERFORCEの設計上で重要な部分は、ネットワークの使用が最小限になるようにデータが配置されていることです。リポジトリのメタデータは中央のサー バ上にあるため、全体的な状態はすべて、アクセスが簡単な1つの場所にあることになります。一方、ユーザが使用するファイルは、高速にアクセスできるよう にローカルディスクにコピーされ、編集、コンパイル、検索などの操作はすべて、ネットワークに依存することなく、ローカルディスクのスピードで実行できま す。 PERFORCE では明示的な操作のみがネットワークを介して行われます。ユーザのクライアントホストと中央のサーバ間でファイルをコピーする場合、PERFORCEはグ ローバル・メタデータを利用して、本当に必要な情報のみを送ります。情報を表示する際にも、PERFORCEサーバはすべてのメタデータに対して高速な ローカルアクセスを行えますので、絞り込まれたデータのみがネットワークを介してクライアントに送られます。
	3.2 TCP/IPベースのメッセージ・キューイング・プロトコル
	クライアントをリポジトリに同期させるために、またリポジトリにファイルを反映するためにファイルを転送する際、PERFORCEはTCP/IP上に直接 構築されたストリーミング・メッセージ・キューイング・プロトコルを使用します。これは、リモート・プロシージャ・コール（RPC）や信頼性の低いデータ グラム(UDP/IP)ベースのNFSには依存しません。

TCP/IPベースの通信方法と、UDPベースのNFSとの違いは重要です。PERFORCEにおいて、ユーザがクライアントからコマンドを実行するとき に、何度かネットワークの遅延時間の影響を受けることがあります。あるネットワーク環境において100msの遅延時間があるとき、ユーザが PERFORCEのクライアントコマンドをタイプしてから、200ms（1/5秒）よけいに時間がかかる場合があります。この程度の遅れは我慢できる程度 のもので、普通は気がつきません。他のすべてのSCMソリューションで要求されるNFSアクセスの場合、ネットワークの遅延時間はファイルの入出力操作 ――これはファイルのチェックアウトのようなシンプルなものを含みます――のたびに影響をおよぼします。その結果、ユーザは1つのファイルをチェックアウ トするのに何分も待つという、非実用的なことになります。

PERFORCEのユーザは、通常の作業をローカルディスク上で行うので、明確にSCMの操作を行う際にだけ、ネットワークのスピードを意識することにな ります。PERFORCEの操作に対するネットワークの遅延時間の影響は、最小限になるよう調整されています。ネットワークのバンド幅のみが、 PERFORCEにおけるパフォーマンスの要因となります。

ネットワークのバンド幅に対するPERFORCEの要求が最も高いのは、リポジトリからクライアント（あるいはその逆）に対して行われるファイル転送で す。基本的にネットワーク環境によってファイル転送率が制限されます。どのくらいの時間をユーザが待たなければならないかは、転送されるファイルの大きさ と数に依存します。変更をリポジトリに反映するときに転送されるファイルは、ユーザによって変更されたファイルですので、たいていの場合少数です。
クライアントがリポジトリと同期をとるときは、他のクライアントで行われた作業を取り込むことになりますので、ファイル数はとても多くなる可能性があります。

ネットワーク環境が、必ずしも制限の要因となるとは限りません。：ネットワークのスピードが1Mbps以上（例としてはT1、T3、イーサネット）のと き、ファイル転送を制限するのはクライアントのディスク容量です。データの量が多いことが原因となるわけではなく、クライアントのディスクに新しいファイ ルが書き込まれることによって、ディレクトリ・エントリが作成されることが原因となります。ほとんどのOS（UNIXを含む）では、ディレクトリのアップ デートは同期的に行われます。これは電源が落ちたり、システム破壊が起こったりしたときにディスク中のデータを守るためには必要なことですが、パフォーマ ンスに対しては大きなハンデとなります。

変更に関するレポートやクライアント情報の編集など、リポジトリとのやり取りがファイルに直接関係しない場合は、通信データ量がとても小さく、ネットワークのバンド幅の影響を受けません。

ユーザの報告から次のようなことがわかっています。ネットワークのスピードが1Mbps以上の場合、PERFORCEにおけるクライアント／サーバ間の情 報のやり取りは、高速LAN上でのそれと同じ程度です。64Kbps(ISDNのスピード)では、ネットワークのスピードはファイル転送に関しては影響が ありますが、レポート表示や他の操作に関しては問題ありません。28.8Kbps(モデムのスピード)では、すべてのオペレーションは確かに影響を受けま すが、それでもPERFORCEを運用する上でさほど大きな問題にはなりません。

以上、まとめるとPERFORCEは高速LAN、低速の社内WAN、（更に低速の）インターネットなど、すべてのTCP/IPネットワークにおいてSCMを実現します。

ネットワークから、すべてのユーザがSCMのリポジトリにアクセスできるようになったときに、最も気になる点はセキュリティです。もちろん、インターネッ トはどの会社のソフトウェア資産にとっても安全な場所ではありませんが、組織内のイントラネットでさえ、大きな会社内の小さなグループにとっては危険にな り得ます。この章では、 ネットワーク上で開発されるソフトウェアを守るために必要な措置について議論します。この措置の重要性は、 開発されるソフトウェアの重要性や、ネットワークの危険度に依存します。

	4.1 レベル1：PERFORCEのプロテクション
	PERFORCE には、ホストのIPアドレスを基盤とした、単純なホスト認証のメカニズムが備えられています。protect コマンドでプロテクションを設定、管理することで、PERFORCEのリポジトリ管理者は、リポジトリにアクセスできるホストを制限することができます。 組織内のイントラネットであれば、多くの場合これで十分です。ホストの任意の集合に対し、リポジトリのどの部分に対しても選択的に、読み取り／書き込みア クセス権限を設定することができるというメリットがあります。これによって、あるホストのユーザに対し、リポジトリのデータは参照できるが編集はできない ようにする、という設定も簡単に行えます。例えば、テクニカル・サポートのチームにはソースコードの参照を許可する、ソフトウェア開発者にはドキュメント の読み取りアクセス権限を与える、などです。 PERFORCEのプロテクション・メカニズムは、ユーザ名をベースにアクセスを制限することもできますが、ユーザ名に対して認証を行うわけではありませ ん。したがって、セキュリティの手段として強要されるものではありません。ただ、ユーザが不本意にリポジトリのデータを修正してしまうようなことを防ぐた めには、いい手段といえます。例えば、コードがリリースのために凍結された場合、製品リリース担当のユーザのみに、リポジトリの該当箇所の読み取り／書き 込みアクセス権限を与えることが可能です。 PERFORCEの プロテクション・メカニズムは、サービスによるアクセス（リソースを使用するためだけの、認証されていないユーザの接続要求）を拒否するようには強化され ていません。そして、クライアント／サーバ間で通信されるデータは暗号化されません。このように、これはスパイ行為を考慮する必要がないような組織内での 使用が、前提となっています。より危険な環境では、ファイアウォールおよび／または強い認証と暗号化が必要です。
	4.2 レベル2：ファイアウォール
	会社が、インターネットに接続されている、または、ネットワークへのアクセスが制御されていないような大きな組織のイントラネットの一部であるというよう な、危険なネットワーク環境を使用する場合、ファイアウォールを使用します。ファイアウォールは、信頼されている LAN と、信頼されていない広域ネットワークとの間のバリアです。 PERFORCE は普通の TCP/IP 接続を使用しますので、認証された PERFORCE の使用を許可できるように、簡単にファイアウォールを設定できます。現在のアクセス環境に対し、ファイアウォールにPERFORCEの接続（デフォルトは ポート番号：1666）を通し、信頼されているホストからのみ、PERFORCEのリポジトリ・サーバへの接続を可能にするだけです。 PERFORCE は適切に設定されているファイアウォール上で正常に動作します。PERFORCEは、TIS(Trusted Information Systems)からフリーで入手できる FWTKというファイアウォールで動作することが確認されています。 TISには商用の製品もあります。要塞ホストが、ファイアウォールを通過するすべての接続を扱い、転送するような FWTK の "plug gateways" を使用した場合でも、PERFORCE は正常に動作します。 ファイアウォール自身は、危険なネットワークに対する有効なプロテクションですが、このような危険なネットワーク上をデータが通過する場合には役立ちません。
	4.3 レベル3：暗号化と強い認証
	ある会社が、組織のネットワーク上での重要なソフトウェア開発を計画した場合、または、ソフトウェア開発をインターネット上で行うことを計画した場合、最 大限のセキュリティの措置、すなわち暗号化と強い認証を実行しなければなりません。強い認証とは、PERFORCEの リポジトリ・サーバに来るTCP/IP 接続が、単にネットワークへアクセスできる誰かからというだけでなく、信頼のあるホストの信頼のあるユーザからのものか検証することを指します。このよう な認証メカニズムは、公開鍵暗号を使用します。暗号化は、単にデータを解読できないように編集し、ネットワーク上にいる人がそのデータを利用できないよう にします。 PERFORCE は、強い認証と暗号化を使用するリモートログインをサポートする、ssh（Secure Shell）というフリーウェア上で動作することが確認されています。ssh上でPERFORCEを使用する場合、ユーザはPERFORCEのリポジト リ・サーバに（sshを介した）ログインアクセスを行わなければなりません。ログインをする際に、ユーザはTCP/IP接続プロキシを有効にするための特 別なフラグを ssh に送ります。このプロキシが、クライアントからのPERFORCE接続を、sshによる安全な暗号化されたパイプを介してサーバに送ります。 実践上、危険な広域ネットワークからLANを守りつつ、認証されたPERFORCEのコネクションを許可するためには、上記のメカニズムを組み合わせて使 用する必要があります。sshは認証と暗号化のために使用され、ファイアウォールは危険な接続を防ぐために使用され、PERFORCEのプロテクションは リポジトリの特定の部分だけにアクセスを制限するために使用されます。その結果、インターネットや組織のイントラネットのどこからのアクセスに対しても、 安全なPERFORCEのリポジトリを構築できます。

ネットワーク上のソフトウェア開発は、現在多くの会社が本当に必要とし、将来的には標準的になるでしょう。PERFORCEは、ネットワーク上でのソフト ウェア開発をサポートする能力を持ちます。そして、いくつかのツールと合わせて用いることで、インターネットや組織のイントラネットを、LAN上のような 開発環境に変えることが可能です。