現在RS232CでPCとある外部機器で通信しているシステムをLAN経由に変更します。PC側はアダプターを入れるのでなく、ソフト自体を書き換えます。外部機器側ははっきりしませんが既存のRS232C通信を何かで変換するのではないかと思います。この場合、通信方式として一般にTCPとUDPが考えられますが、どちらにするべきか決めかねています。それぞれの概略は理解しています。
現在はRS232Cなので、受信データエラーはアプリで判断し再送要求をだす仕組みです。通常は、PCからデータ送信要求を出す⇒外部機器からデータ送信⇒ACK応答⇒EOTの様な手順です(PCからデータを送ることもあります)。この手順をそのまま生かすのであればUDPにするのが妥当なような気がするのですが、TCPの方が一般的とも聞きます。TCPにした場合、通信エラーはTCPプロトコル内でリカバーされるのでアプリの再送要求などは無意味になってしまう用に思えます。解釈が違っているでしょうか。
アプリレベルでの通信手順に大幅な変更を加えないという条件でどちらにするのが妥当なのかご意見をお聞かせください。なお、1回の通信データは長くても200バイト程度で、、通信インターバルは1回/秒程度です。

このQ&Aに関連する最新のQ&A

A 回答 (1件)

>外部機器側ははっきりしませんが既存のRS232C通信を何かで変換するのではないかと思います。



外部機器側がどのような仕様になるか決まらないとPC側が決められないと思いますが、外部機器側の仕様の決定権は質問者さんにあるのでしょうか?

>この手順をそのまま生かすのであればUDPにするのが妥当なような気がするのですが、TCPの方が一般的とも聞きます。TCPにした場合、通信エラーはTCPプロトコル内でリカバーされるのでアプリの再送要求などは無意味になってしまう用に思えます。解釈が違っているでしょうか。

TCPはデータが確実に届くことが保証されるプロトコルであるためこの認識は間違っていないです。
ただ、アプリケーションがプロトコルスタックからデータを受け取ることころまで保証されているわけではないので、全く無駄とまで言い切れないかもしれません。(この場合はアプリケーションのバグってことになりますが)

また、どちらが一般的かはケースバイケースだと思います。

>通信方式として一般にTCPとUDPが考えられますが、どちらにするべきか決めかねています。
>通常は、PCからデータ送信要求を出す⇒外部機器からデータ送信⇒ACK応答⇒EOTの様な手順です(PCからデータを送ることもあります)。

確かに悩ましいところですが、私ならばUDPにすると思います。
理由は
1.現在のプロトコルがTCPでの使用を考慮していないこと、またプロトコルを変更するとアプリの改造が大きくなること
2.TCPコネクションをどうするかを考えないといけないこと
3.TCPは1回の送信が1回の受信で受けられるわけではないので、このへんの考慮がアプリに必要になること
4.TCP再送タイムアウトの問題

判断の参考になるかはわかりませんが、ひとつの意見としてです。
    • good
    • 0
この回答へのお礼

ありがとうございます。参考にさせていただきます。

お礼日時:2011/04/23 04:54

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード


人気Q&Aランキング