0

割り当てられたプロジェクトについてアドバイスを求めており、それが「専門的に」どのように行われたか、または正しい方向に導くことができる提案を探しています.

クライアントからのコマンドを受け取り、バイト ストリームをシリアル ポートにプッシュするサーバー ピースがあります。複数のクライアントがこのサーバー ピースにコマンドを送信できますが、ハードウェアは一度に 1 つのコマンドしか処理できません。私の問題は、ソフトウェア側でのキューイングにあります。

Queue<T>要求しているクライアント番号、メッセージ データ (シリアル ポートに書き込むバイト配列)、およびメッセージ タイプ (コマンドの説明) を含む DataSet にデータを挿入するヘルパー クラスも実装しました。また、DataGrid (フォーム上) にキュー コマンドを一覧表示します。おそらくその方法ではありませんが、要求しているクライアントとデータを保持し、視覚的にキューを表示する限り、それが私が考えることができる唯一のことです。

キューの処理はどこで行うのですか? DataGrid リストが変更された (アイテムが追加/削除された) 場合に、DataSet の最初の行のデータを取得してシリアル ポートに送信するカスタム イベントで処理することを考えました。

コメントや提案は大歓迎です。

ありがとう。

編集:現在実行されているコマンドをキューから削除するには、SerialPort からの応答も必要であることを追加するのを忘れていました。

4

3 に答える 3

0

コマンドのキューを格納するためにデータベース テーブルを使用します。Web アプリがキューにレコードを追加してキューを表示すると、別のプロセス (Windows サービスやコンソール アプリなど) がデータベースから次のコマンドを要求し、それをシリアル ポートに送信します。

于 2011-03-22T18:40:38.577 に答える
0

Client requests can come in at any time, they'll probably be handled by some proxy class (WCF?) on its own thread/task. Then that thread/ task needs to coordinate with the task that's 'inside' the model actually processing the requests.

A good class to do this with is the BlockingCollection.

The server-thread will block until there's something in the collection to work on. It can then take it from the collection in a thread safe manner and process it. Doing it this way ensures that the requests can be accepted when they arrive, but they are processed on at a time.

The overall pattern to think of here is producer-consumer.

GJ

于 2011-03-22T18:45:18.027 に答える