【70191】流れ星 さんの内容について補足
これは三菱に限らない話でありTCPのプロトコル仕様に関係する事です。
TCPのコネクションが突然断路となった場合、冷却時間が必要で、
(記憶によれば、確か４０秒ほどの無処理時間を置いて）
再度接続をトライします。
この場合多くのアプリで３回のリトライ処理を行うので、
（接続待機＋冷却時間）×３の時間のあいだ、再接続モードになります。
同様に、相手側も同様な再接続モードになり、
お互いが手探り状態で再接続を待つようになります。
再接続モードの際に、自局のポート番号を変更すると、
冷却時間を無視して、再接続のトライをすることができます。
ここで問題になってくるのが、
お互い迷走したあげく、３回のリトライを終了してしまった場合であり、
三菱の場合などは、よく「接続不可」などのステータスで表されます。
接続不可のステータスの解除は処理系によって違います。
例を挙げると、三菱の内臓ＣＰＵの簡易リンク機能の場合は、
「接続不可」になると解除方法がありません。ＣＰＵリセットのみです。
ちなみに、「接続不可」というのはプロトコルがTCPであるため
発生する症状で、UDPの場合は発生しません。
これは、TCPがコネクションを切る処理をおこなうまで、
常時コネクションが繋がっていることを前提とした
プロトコルであるためです。
逆にUDPは１送信毎にコネクションが閉じるという送信方法なので
発生しないのです。
そのため、たとえば、１か月とか長い間TCPを維持できる、
という自信や根拠がない場合(再接続体制が万全である事)は、
長時間コネクション保持はおすすめしません。
そういった意味で、UDPがおすすめなのですが、
UDPにはTCPに備わっているエラー訂正機能や、
不達時再送信機能などがありませんので、
パケット到達の確認の厳密性という意味では
アプリケーション側でこれらを実行する必要があります。
【