尾崎と申します。 基本的な質問で申し訳ないのですが、 ソケット(API)を用いてTCP(orUDP)/IPのサーバクライアントアプリケーションは作成できますが、いまUDPアプリケーションにおいてこれにリアルタイム性をもたせるためにRTP(Real-time Transport Protocol)を実装したいのですがやり方がわかりません。 ソフトウェアで実現する場合、どのようにしたらよいのでしょうか？ よろしくお願いいたします。
尾崎さん，始めまして。
私はRTPについて詳しくないので，一般論としての答えしかできませんが．．．
ソケットレベルのやり取りは， RTPの仕様に従ってメッセージを組み立てて送受信するというだけで， それは，RTPのメッセージフォーマットを調べれば済むことです。 要するに，決まったフォーマットに合わせてメッセージを作るだけ，ということです。 しかし，それでリアルタイム性を実現できるわけではありません。
一般的に言って，TCP/IPのプロトコル処理ソフト自身には， リアルタイム性を保証するような考え方はありません。 仮に，UDP上でRTPメッセージを運ぶものとすると， プロトコル処理ソフトはアプリケーションから UDPメッセージをもらって，単純に送信するだけです。 受信のときは，これとは逆に， 受信したUDPメッセージを単にアプリケーションに渡すだけです。 要するに，UDPメッセージ中身がRTPという仕様で定められた フォーマットに従って作ってあるというだけのことで， RTPというプロトコルの役割も意味も一切関知しません。 リアルタイム性は，アプリケーション側の作り方と パケットを運ぶネットワークの設計によって， 実現可否が決まる，といえるでしょう。
RTPには，確か，タイムスタンプのような情報があって， それでタイミングをとるような仕組みがあったと思いますが， 送信時にタイムスタンプに値をセットするのも， 受信時にタイムスタンプの値と見て，時間に関する何らかの制御を行うのも すべてアプリケーション側の問題となります。
さらに，単にRTPのメッセージを送れば，それがある時間内に相手に届く， というような保証もありません。 つまり，RTPのパケットだからといって， 何の設定もなしに，ルータやスイッチが特別扱いすることはないので， 混雑すれば，パケットは遅れて到着します。 それを防ぐには，RTPのパケットを優先的に配送するといった， ネットワーク側の設計や設定が必要です。
ということで，そういったことを総合的に考えないと， つまり，システム全体で考えないと リアルタイムアプリケーションは作れないはずです。
早速の返答ありがとうございました。 UDPの上位にRTPをのせたアプリケーションということは、 TCPの上位にHTTPをのせたWebブラウザのようなものでしょうか。 結局、WebブラウザやQuickTimeの類を作るというようなものだと理解しました。 ちょっと大変かもしれないです。
>UDPの上位にRTPをのせたアプリケーションということは、 >TCPの上位にHTTPをのせたWebブラウザのようなものでしょうか。
TCP/IPプロトコル処理ソフトは，HTTPのメッセージも単なるデータの塊と見なし， その意味や性質などは関知しませんし， HTTPの意味や性質の部分は，Webサーバやブラウザがハンドリングします。 プロトコル処理ソフトとアプリケーションという関係で言えば， RTPとTCP/IPの関係とHTTPとTCP/IPの関係はよく似ているといえます。
>結局、WebブラウザやQuickTimeの類を作るというようなものだと理解しました。
まあ，そういうことですね。 システム全体で考えると，クライアント側だけでなく，サーバ側も必要ですから， Webサーバや，QuickTimeサーバあるいはRealSystemのサーバも 合わせて作らなくてはいけないことになりますね。
>ちょっと大変かもしれないです。
WebやRealの場合は，多機能でシステム規模が大きいですから，確かに大変です。 どんな内容のものでも，大規模なシステムを作るのは大変です。 でも，機能を絞り込んだ小規模なシステムなら， 必ずしもそうとは限りません。
コメント
システム全体でリアルタイム性の実現手法を考えないといけないでしょう
尾崎さん，始めまして。
私はRTPについて詳しくないので，一般論としての答えしかできませんが．．．
ソケットレベルのやり取りは，
RTPの仕様に従ってメッセージを組み立てて送受信するというだけで，
それは，RTPのメッセージフォーマットを調べれば済むことです。
要するに，決まったフォーマットに合わせてメッセージを作るだけ，ということです。
しかし，それでリアルタイム性を実現できるわけではありません。
一般的に言って，TCP/IPのプロトコル処理ソフト自身には，
リアルタイム性を保証するような考え方はありません。
仮に，UDP上でRTPメッセージを運ぶものとすると，
プロトコル処理ソフトはアプリケーションから
UDPメッセージをもらって，単純に送信するだけです。
受信のときは，これとは逆に，
受信したUDPメッセージを単にアプリケーションに渡すだけです。
要するに，UDPメッセージ中身がRTPという仕様で定められた
フォーマットに従って作ってあるというだけのことで，
RTPというプロトコルの役割も意味も一切関知しません。
リアルタイム性は，アプリケーション側の作り方と
パケットを運ぶネットワークの設計によって，
実現可否が決まる，といえるでしょう。
RTPには，確か，タイムスタンプのような情報があって，
それでタイミングをとるような仕組みがあったと思いますが，
送信時にタイムスタンプに値をセットするのも，
受信時にタイムスタンプの値と見て，時間に関する何らかの制御を行うのも
すべてアプリケーション側の問題となります。
さらに，単にRTPのメッセージを送れば，それがある時間内に相手に届く，
というような保証もありません。
つまり，RTPのパケットだからといって，
何の設定もなしに，ルータやスイッチが特別扱いすることはないので，
混雑すれば，パケットは遅れて到着します。
それを防ぐには，RTPのパケットを優先的に配送するといった，
ネットワーク側の設計や設定が必要です。
ということで，そういったことを総合的に考えないと，
つまり，システム全体で考えないと
リアルタイムアプリケーションは作れないはずです。
Re システム全体でリアルタイム性の実現手法を考えないといけないでしょう
早速の返答ありがとうございました。
UDPの上位にRTPをのせたアプリケーションということは、
TCPの上位にHTTPをのせたWebブラウザのようなものでしょうか。
結局、WebブラウザやQuickTimeの類を作るというようなものだと理解しました。
ちょっと大変かもしれないです。
大規模なシステムは大変ですが．．．
>UDPの上位にRTPをのせたアプリケーションということは、
>TCPの上位にHTTPをのせたWebブラウザのようなものでしょうか。
TCP/IPプロトコル処理ソフトは，HTTPのメッセージも単なるデータの塊と見なし，
その意味や性質などは関知しませんし，
HTTPの意味や性質の部分は，Webサーバやブラウザがハンドリングします。
プロトコル処理ソフトとアプリケーションという関係で言えば，
RTPとTCP/IPの関係とHTTPとTCP/IPの関係はよく似ているといえます。
>結局、WebブラウザやQuickTimeの類を作るというようなものだと理解しました。
まあ，そういうことですね。
システム全体で考えると，クライアント側だけでなく，サーバ側も必要ですから，
Webサーバや，QuickTimeサーバあるいはRealSystemのサーバも
合わせて作らなくてはいけないことになりますね。
>ちょっと大変かもしれないです。
WebやRealの場合は，多機能でシステム規模が大きいですから，確かに大変です。
どんな内容のものでも，大規模なシステムを作るのは大変です。
でも，機能を絞り込んだ小規模なシステムなら，
必ずしもそうとは限りません。