現在、IIS サーバーによって提供される xml のビューをレンダリングするデバイスを使用しています。残念ながら、デバイスは Cookie もリダイレクトもサポートしていないため、通常の asp.net セッションまたは Cookie なしのセッションの両方の使用が無効になります。
データが url クエリ文字列で許可されているサイズを超えているため、これもオプションではありません。
私がやりたかったのは、セッション ID (URL クエリ文字列で渡されるデバイスの MAC アドレスである可能性があります) を明示的に伝えることができる、ある種のカスタム セッション メカニズムを持つことです。
SQLデータベースを使用できましたが、それを避けたかったのです。
何か案は？
編集：
ソリューションがロード バランサーで実行されるという通知を受け取ったので、実際に SQL ソリューションを使用するようです。どちらも有効な返信をありがとうございますが、これにはあまり選択肢がないようです...
必要なのは、ユーザー固有のキーだけです。Mac アドレスにアクセスできる場合は、それを使用します。私はおそらく GUID を選択し、そのラウンドをクエリ文字列に渡します。
サーバー側では、データベースアプローチ（または任意の形式のファイルストレージですが、クエリパフォーマンスのために最適化されたDB）を使用するか、情報をメモリに保存できます。各「一意のキー」に対してデータを関連付ける静的辞書型クラスを作成します。その後、データを簡単にクエリできます。
セッションの有効期限が切れたときに解決する必要がある場合は、より困難な部分が発生します。データベース アプローチを採用する場合は、Windows サービスを記述して「最終更新セッション」フラグを照会し、指定された時間を過ぎてセッションが期限切れになった場合にセッションを削除できます。「メモリ内」アプローチを選択した場合、これはおそらく管理がはるかに難しくなります。
「メモリ内」オプションのもう 1 つの欠点は、格納する情報が多すぎて、使用可能なメモリが使い果たされないように注意する必要があることです。これが、データベース ストレージを使用する主な理由です。
ユーザーがリンクをクリックするたびにセッション データを渡すすべてのインタラクションを POST にしたい場合を除き、状態をどこかに (データベースなど) に保存し、軽量 ID (あなたが説明したMACアドレスのように）。
もちろん、SQL データベースである必要はありません 。redisなどの他のストレージ メカニズムを見ることができます。