1

ですから、私は過去に iso スタック セッション レイヤーのような大規模なシステムに取り組んできましたが、そのようなものは私が必要とするものには大きすぎますが、全体像についてはある程度理解しています。私が今持っているのは、いくつかのコンポーネントが（しばしば）データをドロップしているシリアルポイントツーポイント通信リンクです。

そのため、トランスポートに使用する独自の信頼できる配信システムを作成する必要があります。誰かが基本的なアルゴリズムの方向性を教えてくれますか、またはそれらが何と呼ばれているかについての手がかりを与えることさえできますか? 私はグーグルを試しましたが、遺伝的アルゴリズムなどに関する大学院の理論に行き着きました。基本が必要です。たとえば、純粋な C の 10 ～ 20 行。

4

5 に答える 5

1

  1. Xモデム。古くて悪いですが、ハードウェアとソフトウェアの両方で広くサポートされており、文字通りすべての言語と市場のニッチでライブラリを利用できます.

  2. HDLC - ハイレベル データ リンク コントロール。これは、TCP/IP を含む、過去 30 年間に多くの信頼できるプロトコルの父となったプロトコルです。直接使用することはできませんが、独自のプロトコルを開発するためのテンプレートです。基本的な前提は次のとおりです。

    • すべてのデータ バイト (またはパケット) に番号が付けられます
    • 通信の両側でローカルに 2 つの番号を維持します: 最終受信と最終送信
    • すべてのパケットには 2 つの数値のコピーが含まれています
    • 成功した送信はすべて、更新された数値を含む空の (またはそうでない) パケットを送り返すことによって確認されます。
    • タイムアウト時間内に送信が確認されない場合は、再送信します。

    特別な処理 (同期) のために、パケットにフラグを追加します (多くの場合、パケットが特別で使用されることを伝えるには、1 ビットだけで十分です)。CRCもお忘れなく。

どちらのプロトコルにも、いかなる種類のセッション サポートもありません。しかし、単純なステート マシンとタイマーという別のレイヤーを追加するだけで導入できます。

  • セッションは特別なパケットで始まります
  • 指定されたタイムアウト内に少なくとも 1 つの (空の可能性がある) パケットが存在する必要があります
  • こちら側が timeout/2 内にパケットを送信しなかった場合は、空のパケットを送信します
  • タイムアウト内に通信の反対側からパケットが見られなかった場合、セッションは終了しています
  • 正常なセッション終了のために別の特別なパケットを使用できます

これは、セッション制御が得られるのと同じくらい簡単です。

于 2015-01-29T09:09:42.957 に答える
0

送信側。

/////////////////////////////////////////  XBee logging
void dataLog(int idx, int t, float f)
{
    ubyte stx[2] = { 0x10, 0x02 };
    ubyte etx[2] = { 0x10, 0x03 };

    nxtWriteRawHS(stx, 2, 1);
    wait1Msec(1);

    nxtWriteRawHS(idx, 2, 1);
    wait1Msec(1);

    nxtWriteRawHS(t, 2, 1);
    wait1Msec(1);

    nxtWriteRawHS(f, 4, 1);
    wait1Msec(1);

    nxtWriteRawHS(etx, 2, 1);
    wait1Msec(1);
}

受信側

void XBeeMonitorTask()
        {
            int[] lastTick = Enumerable.Repeat<int>(int.MaxValue, 10).ToArray();
            int[] wrapCounter = new int[10];


            while (!XBeeMonitorEnd)
            {
                if (XBee != null && XBee.BytesToRead >= expectedMessageSize)
                {
                    // read a data element, parse, add it to collection, see above for message format
                    if (XBee.BaseStream.Read(XBeeIncoming, 0, expectedMessageSize) != expectedMessageSize)
                        throw new InvalidProgramException();

                    //System.Diagnostics.Trace.WriteLine(BitConverter.ToString(XBeeIncoming, 0, expectedMessageSize));

                    if ((XBeeIncoming[0] != 0x10 && XBeeIncoming[1] != 0x02) ||  // dle stx
                        (XBeeIncoming[10] != 0x10 && XBeeIncoming[11] != 0x03))   // dle etx
                    {
                        System.Diagnostics.Trace.WriteLine("recover sync");
                        while (true)
                        {
                            int b = XBee.BaseStream.ReadByte();
                            if (b == 0x10)
                            {
                                int c = XBee.BaseStream.ReadByte();
                                if (c == 0x03)
                                    break;     // realigned (maybe)
                            }
                        }
                        continue;   // resume at loop start
                    }

                    UInt16 idx = BitConverter.ToUInt16(XBeeIncoming, 2);
                    UInt16 tick = BitConverter.ToUInt16(XBeeIncoming, 4);
                    Single val = BitConverter.ToSingle(XBeeIncoming, 6);

                    if (tick < lastTick[idx])
                        wrapCounter[idx]++;
                    lastTick[idx] = tick;

                    Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => DataAdd(idx, tick * wrapCounter[idx], val)));
                }
                Thread.Sleep(2);  // surely we can up with the NXT
            }
        }
于 2012-09-10T14:23:46.170 に答える
0

さらに考えてみると、最初の 2 つの回答に対するあなたの回答を検討した後、これはハードウェアの問題を示しており、巧妙なコードでそれを修正することはできません。

リンクにオシロスコープを接続することをお勧めします。これは、障害の場所を特定するのに役立ちます。特に、2 つの側 (Tx、Rx) のボーレートを調べて、それらが仕様の範囲内であることを確認します...自動ボーはしばしば問題になります?!

ただし、ドロップアウトが定期的に発生するか、または他のアクティビティと同期できるかどうかを確認してください。

于 2012-09-09T19:08:04.633 に答える
0

この質問には（IMO）2つの側面があります。

まず、データがドロップされている場合は、最初にハードウェアの問題を解決することを検討します。そうしないと、GIGO が発生します。

通信プロトコルに関しては、あなたの投稿はかなり些細なシステムを示唆していますか? データを検証したいですか (パリティ、サムチェック?)、またはエラー訂正を含めようとしていますか?

検証だけが必要な場合は、RS232 と CRC8 サムチェックを使用して信頼性の高いシステムを実行しています。その場合、この StackOverflow ページがおそらく役立ちます

于 2012-08-27T06:56:30.553 に答える
0

一部のコンポーネントがシリアル ポイント ツー ポイント リンクでデータをドロップしている場合、コードに何らかのバグが存在するはずです。

まず、物理層の通信に問題がないことを確認してください。

次に、ARQ（自動リクエスト再送信）などのデータ通信理論に関する知識が必要です。

于 2012-08-27T07:03:54.217 に答える