以下備忘録。
本家はVisual C++で実装。
IPMSG_DELMSG & IPMSG_RELEASEFILESの仕様
IPMSG_DELMSGは、受信者がメッセージを破棄 Receiver discards message した時に使う。
Receiver -> Sender
受信側はIPMSG_SENDMSGの応答としてIPMSG_RECVMSGを送信しているはずなので、IPMSG_DELMSGはあまり意味が無い気がする。
送信側はメッセージ全文をSENDMSGに乗せていて、
受信側はメッセージ全文を受け取っている。
読んでいませんとDELMSGを送られても、送信側は信用することができない。※たとえ、IPMSG_SECRETOPT封書指定で未開封であっても。
※Open Protocolであるため本家以外のIPMクライアントを想定しなければならない。もっと言うなら、悪意を持ったIPMクライアントがいる可能性もある。
※本家Ver4.99で非対応コマンド。送信・受信しない。ソース上に定数定義のみ存在する。
逆のケースを考えると、「誤送信したメッセージを取り消したい」というニーズは常にある。
だが、DELMSGをSender -> Receiverへ送ったとしても、削除を認めるかどうかは相手に委ねられるため、所詮"おねがい"である。
もし、「取り消し」機能を実装するならば、
IPMSG_RELEASEFILESは、受信者が添付ファイルのダウンロード完了時など Receiver completes downloaded, etc 、添付情報が不要になった時 No attachment required に使う。
Receiver -> Sender
メッセージとデータの一貫性を保つためにTCP転送用のファイルをメモリ上にキープするようなIPM実装があるかもしれない。
その場合、システムリソースを適切に解放することが可能になる。
本家Ver4.99には実装されていないが、このコマンドはSender -> Receiver で使用したい場合もある。
送信側で添付したファイルが、「HDDから削除」や、
「誤って添付した」場合などである。
送信側がリクエストを拒否すれば済む話だが、無駄なTCPセッションが発生する。また、破棄されたことを認識していないIPMクライアントが、無駄なリトライを繰り返す事を阻止できる。
Receiver -> Sender
受信側はIPMSG_SENDMSGの応答としてIPMSG_RECVMSGを送信しているはずなので、IPMSG_DELMSGはあまり意味が無い気がする。
送信側はメッセージ全文をSENDMSGに乗せていて、
受信側はメッセージ全文を受け取っている。
読んでいませんとDELMSGを送られても、送信側は信用することができない。※たとえ、IPMSG_SECRETOPT封書指定で未開封であっても。
※Open Protocolであるため本家以外のIPMクライアントを想定しなければならない。もっと言うなら、悪意を持ったIPMクライアントがいる可能性もある。
※本家Ver4.99で非対応コマンド。送信・受信しない。ソース上に定数定義のみ存在する。
逆のケースを考えると、「誤送信したメッセージを取り消したい」というニーズは常にある。
だが、DELMSGをSender -> Receiverへ送ったとしても、削除を認めるかどうかは相手に委ねられるため、所詮"おねがい"である。
もし、「取り消し」機能を実装するならば、
- 送信側で取り消し有効期間として1分程度の遅延送信を行う
IPMSG_RELEASEFILESは、受信者が添付ファイルのダウンロード完了時など Receiver completes downloaded, etc 、添付情報が不要になった時 No attachment required に使う。
Receiver -> Sender
メッセージとデータの一貫性を保つためにTCP転送用のファイルをメモリ上にキープするようなIPM実装があるかもしれない。
その場合、システムリソースを適切に解放することが可能になる。
本家Ver4.99には実装されていないが、このコマンドはSender -> Receiver で使用したい場合もある。
送信側で添付したファイルが、「HDDから削除」や、
「誤って添付した」場合などである。
送信側がリクエストを拒否すれば済む話だが、無駄なTCPセッションが発生する。また、破棄されたことを認識していないIPMクライアントが、無駄なリトライを繰り返す事を阻止できる。
0 件のコメント:
コメントを投稿