1

複数のクライアント プログラムが単一のサーバー プログラムと通信し、すべてが単一の Windows コンピュータで実行されている場合、どのような方法が最適ですか? すべてVB6で書かれています。この問題を解決する方法についての推奨事項をいただければ幸いです。

注: .NET への移行に取り組んでいますが、.NET の準備が整う前に、V6B バージョンに機能を追加する必要があります。

可能性には、TPC 接続、名前付きパイプ、共有メモリ、メッセージ、ファイルなどが含まれます。

クライアントはサーバーに文字列を入力として渡し、サーバーはそれをサーバーだけが知っているデータと組み合わせて、クライアントに返される別の文字列を生成します。どちらの文字列も約 100 文字の長さしかありません。サーバーは、新しいファイルを開く必要がある場合にのみ接続されるため、通信量は非常に少なくなります...おそらく、15 秒以内に 10 回の呼び出しが殺到し、その後 1 時間のアイドル時間が続きます。

しかし、2 つのクライアントがほぼ同時に情報を要求することを選択する可能性があります。サーバーは各リクエストを 1 秒未満で処理し、数秒の遅延はどのプログラムにとっても重要ではないため、ブロック/ロックは確かに許容されます。

サーバーのアルゴリズムは複雑で、アプリケーションにとって重要ないくつかの理由から、各ヘルパー プログラムで複製すべきではありません。それがサーバーが必要な理由です。

背景:
既存の大規模なレガシー プログラムに機能を追加しています。この単一のプログラムには、ヘルパーとして機能し、ユーザーが特定の選択をしたときに実行される他のいくつかのレガシー プログラムがあります。これらのプログラムはシェル コマンドで開始され、単なる個別のスレッドではありません。たとえば、あるヘルパーは DVD ドライブから新しいデータをハード ドライブにロードします。別のヘルパーは、惑星の現在位置のチャートを表示するだけです。

これは、たまたま VB6 で書かれた大規模な商用レガシー プログラムです。私たちはそれとすべてのヘルパー プログラムを .NET に変換する作業を行っていますが、最初に vb6 でこの機能が追加された新しいバージョンをリリースする必要があります。(私たちはすでに別の場所に移動しているので、VB6 を使用しないように言わないでください。) 一時的な VB6 ソリューションが必要です。

4

2 に答える 2

5

VB6は、ProおよびEnterpriseEditionに含まれている標準のWinsockControlコンポーネントを介してTCPおよびUDPを非常にうまく実行します。しかし、多くのシェードツリーコーダーはそれに苦労しているようです。VB6の他のネイティブIPCはCOM/DCOMとDDEのみであるため、これはおそらく最も明白なルートですが、MSMQはVB6にも優れたサポートを提供しました。

IPベースのプロトコルの欠点は、名前空間が制限され、衝突の可能性が高くなることです（64Kポート番号、多くは標準アプリケーション用に確保されている、エフェメラルポート範囲など）。それらもやや「重量級」ですが、まだ稼働中の最も古いPCの膨大なリソースと、トラフィックの少ない要件を考慮すると、決定する際にそれを無視できます。

検討したもう1つのオプションは、名前付きパイプです。

これはあなたの状況で多くの利点を提供します。一つには、名前空間ははるかに大きく、一意の名前だけが必要です。これは、Win9x後の時代には、最大256文字の長さになり、一意性をかなり簡単に実現できます。もう1つは、ファイアウォールで「ファイルと印刷の共有」が許可されている限り、すべてがその最前線に設定されているということです。

また、アプリケーションでは、任意の双方向ストリームやメッセージではなく、RPCスタイルのメカニズムのみが必要なようです。 TransactNamedPipe()クライアントでの呼び出しが理想的かもしれません。名前付きパイプはLAN上で機能しますが、1台のPC内では、非常に高速で軽量です。

VB6には名前付きパイプコンポーネントが付属していませんが、非常に高いパフォーマンスが必要とされない限り、このようなものはかなり簡単に作成できます。オーバーラップしたI/Oを実装して非同期性を取得する代わりに、サーバーでタイマーベースのポーリングを使用できます。私は数年前に1つをまとめ、このアプローチで幸運を祈りました。

しばらく前に、 PipeRPC-RPC OverNamedPipesでかなり安定した表現を公開しました。使用例とドキュメントが記載された、古いバージョンとやや新しいバージョンがあります。設計どおり、クライアントは「呼び出し」を行い、要求パラメーターのバイト配列を渡し、応答結果のバイト配列を受け取ります。変更なしでUnicode文字列を押し出すこともでき、コンパイラに型を強制させることができます。

クライアントとサーバーの両方に対して、1つの「ドロップイン」UserControl。

この質問を振り返って：

サーバーのアルゴリズムは複雑であり、アプリケーションにとって重要ないくつかの理由から、各ヘルパープログラムで複製しないでください。それがサーバーが必要な理由です。

それが本当に懸念事項である場合は、すべてのプログラムが使用する共有DLLを作成しないのはなぜですか？

于 2012-09-16T01:14:14.717 に答える
2

新しいプラットフォームに移行する既存の VB6 アプリケーションへの 1 回限りのアップグレード リリースの場合、変更をできるだけ単純かつ簡単に保つことを強調します。その結果、共有メモリや比較的珍しいものを含むルートをたどることはありませんでした。

いくつかのオプション、完全に単純なものはありませんが、少なくともいくつかのアイデア:

  • 変換を実行するサーバー コードで COM オブジェクトを公開し、クライアント アプリで使用できるようにします。クライアントは、サーバーからのオブジェクトをアウトプロセス オブジェクトとしてインスタンス化し、COM にすべてのマーシャリングなどを処理させます。

  • サーバーはネットワークを認識していますか? VB6 は、sockets/tcp をネイティブにうまく処理できませんが、それを追加する理由があれば、それを利用してソケットベースの接続とデータ交換を実行できる可能性があります。

  • サーバーとクライアントはそれぞれ、説明した翻訳サービスのインバウンド/アウトバウンド要求を構成する特定のファイルの存在について、共通のリソース フォルダーをポーリングできます。あまりエレガントではありませんが、最も単純かもしれません。

いくつかのアイデアを考えてみてください。それが何らかの形で役立つことを願っています。幸運を！

于 2012-09-15T13:06:49.123 に答える