[メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法

HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か（ピアがメッセージの処理を開始した否か）を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下本題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト／レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装

[kasumani]

TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法 HTTP/1. Tags: feedly, ifttt, recently read, saved for later from Pocket February 13, 2015 at 09:24PM via IFTTT

[moccos_info]

後者、NACK届く保証ないから完璧にはならずとも、かなりましになる感じかな？

[clavier]

Kazuho's Weblog: [メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法

[onionskin]

でも結局アプリレイヤでACK返さないと救われないケースが多いんじゃないかなぁ。サーバやプロキシがkillされたときとか。

[hiroshi_revolution]

Kazuho's Weblog: [メモ] TCP上（もしくはHTTP）にリトライ可能なアプリケーションプロトコルを実現する方法

[kazuhooku]

blogged