問題タブ [dce]

XML-RPCの事実上の C/C++ 実装におけるXML- RPC-C/C++と比較して、Microsoft RPC NDR エンジン( DCE 1.1 )の特定の一般的な型付きデータのエンコード/デコードに関するベンチマークはありますか?

実際、 Windowsでハイ パフォーマンス コンピューティング用の独自の共通オブジェクト インフラストラクチャを実装するには、 Windows RPCとXML-RPC-C/C++ のどちらかを選択する必要があります。彼らのパフォーマンスに関して、どのような推奨事項がありますか? ありがとうございました。

よろしくお願いします、

ヤン

今、samba によって実装された dcerpc ライブラリによって、rpc サーバーとクライアントを作成するタスクがあります。過去 4 日間に samba.org とソースから情報を入手したかったのです。残念ながら、私には何も役に立ちません。

samba の rpc 実装によって rpc サーバーとクライアント (RPC Helloworld) を作成するための例またはチュートリアルはありますか?

ありがとう

Windows サーバーへの SMB および RPC 呼び出しを使用してレジストリからデータを取得する、Linux 5.5 でホストされているアプリケーションがあります。

問題は、wireshark トレースを確認すると、bind_nak の理由でプロトコル バージョンがサポートされていないことを示す Windows サーバーからの応答が表示されることです。Linux サーバーがメジャー バージョン 5 とマイナー バージョン 0 を使用していることがわかります。Windows 2008 サーバーで試してみました。同じ問題が見られます。このため、必要なデータを取得できません。

問題を解読する方法はありますか？Windows/Linux サーバーで何を探しますか。

注: - SMB プロトコルを使用した初期の往復は成功しています。つまり、wireshark トレースで、プロトコルのネゴシエーションがあったことを確認できます。次に、セッション セットアップと x 要求、セッション セットアップと x 応答、NT 作成と x 要求、NT 作成と x 応答などのコマンドを確認できます。

すべてのコンポーネントを取得するには、Profinet ネットワークをチェックする必要があります。NSMP または DCP 経由で問い合わせることもできますが、その後 RPC 経由で関数を実行するには UUID が必要です。

問題は、Windows NT では機能する LookUpBegin(next and stop) という名前の関数があったことですが、Vista OS 以降ではサポートされていません。ここに何かがあるに違いないことがわかりましたが、それが何であるか、どこにあるのかを見つけることができませんでした...

C++ で DCE-RPC を使用した経験はありますか? 最良の方法？サンプルはありますか？なんでもいい。

もう 1 つの質問は、不明なデバイス サーバーで関数を実行する必要があるということです。IDまたは類似のものと文字列を与える関数を実行できるRPCの関数はありますか? サーバーに送信する一種のソケットで、適切にコーディングされていれば、サーバーは何かを実行します。Wireshark 経由でトレースを盗聴できたからです。それで、私は彼らの一部を知ることができました。

Direct Code Execution (DCE) - ネットワーク シミュレータ ns-3 の拡張機能で、偽の POSIX レイヤーを提供することでシミュレータ内で実際のプログラム (VLC、iperf) を実行できます - ubuntu へのアップグレード以来、成功していません。ゼニアル。DCE をコンパイルするには、最初にプログラムを実行./waf configureし、最後にプログラムをビルドします。

これを修正するためのアイデアが不足していることを認めます。コンパイラをアップグレードしたときに最初に発生しました： gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)

詳細: https://github.com/direct-code-execution/ns-3-dce/issues/46

の結果は次のとおりです: ./waf build -v https://transfer.sh/tj7uf/temp

そしてhttps://transfer.sh/qE5Cd/link-stepでの結果:

(R_X86_64_PLTOFF64 を検索)

何かヒントがあればお待ちしております

乾杯

RFC 4122 ( Universally Unique IDentifier (UUID) URN Namespace ) では、「クロック シーケンス」という用語が使用されています。

4.1.5. クロック シーケンス

UUID バージョン 1 の場合、クロック シーケンスを使用して、クロックが時間を遡って設定された場合やノード ID が変更された場合に発生する可能性のある重複を回避します。

クロックが逆に設定されている場合、または逆に設定されている可能性がある場合 (たとえば、システムの電源がオフになっている間)、UUID ジェネレーターは、クロックが設定された値よりも大きいタイムスタンプを持つ UUID が生成されていないことを確認できません。その場合、クロック シーケンスを変更する必要があります。クロック シーケンスの以前の値がわかっている場合は、インクリメントするだけです。それ以外の場合は、ランダムまたは高品質の疑似乱数値に設定する必要があります。

同様に、ノード ID が変更された場合 (ネットワーク カードがマシン間で移動された場合など)、クロック シーケンスを乱数に設定すると、マシンのクロック設定のわずかな違いによる重複の可能性が最小限に抑えられます。変更されたノード ID に関連付けられたクロック シーケンスの値がわかっている場合は、クロック シーケンスをインクリメントするだけで済みますが、そうはなりません。

クロック シーケンスは、システム間の相関を最小限に抑えるために、最初に (つまり、システムの有効期間内に 1 回) 乱数に初期化する必要があります。これにより、システムからシステムへと急速に移動または切り替わる可能性があるノード識別子に対して最大限の保護が提供されます。初期値は、ノード識別子に関連付けてはなりません。

UUID バージョン 3 または 5 の場合、クロック シーケンスは、セクション 4.3 で説明されている名前から構築された 14 ビット値です。

UUID バージョン 4 の場合、クロック シーケンスは、セクション 4.4 で説明されているように、ランダムまたは疑似ランダムに生成された 14 ビット値です。

この用語はどういう意味ですか?