参考までに、ファイルコピーだけが目的なら、Windowsのファイル共有より、
FTPの方が速いです。

サーバ側にはIIS(Internet Information Server : OS種によっては標準添付)
を入れるのが手っ取り早いです。LinuxサーバならApacheなど。
フリーソフトのFTPサーバもたくさんあります。

クライアント側アプリは、MFCベースなら、以下のHPに詳しく解説があります。
http://www.g-ishihara.com/mfc_pt_01.htm

　まず、どの程度の速度を目標値におくか、が明確にならないと性能上げのチューニング
は成果が上がりません。
　どこがボトルネックになってるのかを測定し、理論限界値はいくつなのかを計算するこ
とから始められるのが良いと思います。
　ネットワーク越しのファイルのコピーだと、考えるべき内容が多いので、いくつか分割
して考えると良いでしょう。

　たとえば、すでに述べられていますがHUBとの構成や、ネットワークの接続速度を上げ
るのは、ハードウェア/環境設定など、アルゴリズムとは無関係ですが、大幅に性能が上
がります。

　次に、アルゴリズム的な話をすると、ファイルコピーをマルチスレッド化すると、一般
的にファイルコピー速度は低下します。
　エクスプローラーでも同じなので、検証してみてください。
　ですから、高速化のためにマルチスレッド化・・・というアプローチは間違いです。
　HDDのベンチマークを見る機会があると思いますが、シーケンシャルな読み書きと、ラ
ンダム読み書きで速度が桁違いなのはご理解いただけると思いますが、マルチスレッド化
すると、必然的にランダムアクセスを多用することになる事が原因です。
　ストライピングなどのハード構成でもない限り、HDDは基本的にシングルスレッドで扱
うのが最も効率的です。

　シングルスレッドでファイルコピーを行う場合は、コピーの際の読み/書きを行うバッ
ファを大きくとる事がもっとも効率的に処理を行えます。
　最近のエクスプローラは知りませんが、NT4の頃はこのバッファサイズが4KBちょいしか
ありませんでした。
　4KBごとに、読み/書き/読み/書き/読み/書きと繰り返してたわけです。
　FireFileCopyなどは、このバッファサイズをメガバイト単位で取得することで、高速化
しているはずです。

　余談ですがFTPが速いってのは、16KBだったか64KBだったかうろ覚えですがFTPのバッ
ファが大きいことによるものと思います。

一応、補足です。
頻繁に読み書きを繰り返すと遅くなる理由は、
（ヘッド動かす）読み/（ヘッド動かす）書き/（ヘッド動かす）読み/（ヘッド動かす）書き
のようになり、HDDの回転を待つシークタイムが発生するためです。
連続領域に、続けて読み/書きできれば高速化できるのは、必然といえるでしょう。

今、使えるか情報か分かりませんが、MS社の説明文がありましたので紹介しておきます。
http://support.microsoft.com/kb/223140/ja?wa=wsignin1.0

ん？
もしかして、
１台のＰＣ、データ提供側のＰＣもXPですか？
ピアーツーラン接続ですか？
たぶん、サーバーOSを使いドメイン接続で使わないと3台のPCの状況でLANのスピードが
変わってしまうと思います。
重たい処理で遅くなっているPCがあるとそのPCにあわせるようになるので、結果速度
がおそくなると思います。
FTPサーバのフリーソフトがあるので、安く済ませるのならFTP接続かなと思います。
ただその場合はFTP接続でソフトを組まないとだめです。

修正
ピアーツーラン接続→ピアーツーピア接続
です。

一応　ある程度成果が出ましたので　書いておきます。
私がした方法は　CopyFileを　freadとfwriteに換え、メモリを毎回確保せずに、
最初に大き目のメモリを取って流用する方法です。
おそらく　2000ものファイルを　並列(3個）にCopyFileをすることで　
メモリの確保が乱発し何かよくないことが起こっていたのでしょう。
（私の知識ではこれぐらいしかわかりません。）
現状　fwriteで待っている感があるのですが　これについては
LANがボトルネックになっているので...

私の知識が少なく すべての助言をいかせきれず
こんな単純な方法で　解決とするのは　心苦しいですが
皆様　いろいろな助言をくださりありがとうございました。