クライアント側が無線リンクを介してサーバーにデータをアップロードするアプリケーションを作成しています。
接続は非常に信頼できる必要があります。リンクは何度も切断されることが予想され、多くのクライアントがサーバーに接続されます。
TCP を使用するか信頼できる UDP を使用するかについて混乱しています。
あなたの考えを共有してください。
ありがとう。
5580 次
4 に答える
6
もちろん、RUDP は正式な標準ではありません。使用できる既存の実装が見つかるかどうかはわかりません。これをゼロから展開するか、単に TCP 接続を再作成するかの選択肢が与えられた場合、私は TCP を選択しました。
于 2010-11-14T20:46:44.657 に答える
5
安全のために、信頼できる標準プロトコルであるという理由だけで TCP を使用します。RUDP には、確立された標準ではないという欠点があります (ただし、いくつかの IETF の議論で言及されています)。
あなたのプロジェクトで頑張ってください！
于 2010-11-14T20:47:02.570 に答える
3
TCP リンクと RUDP リンクの両方が環境によって切断される可能性が高いため、RUDP を使用しているという事実がそこで役立つ可能性は低いです。データグラムが通過できない場合があります...
実際に確認する必要があるのは、a) 接続されているクライアントの数を処理できること、b) クライアント (またはサーバー) との接続が失われたときにアプリケーション プロトコルが合理的に迅速に検出できること、および c) 接続されているクライアントを処理できることです。クライアントの相互接続セッション状態の再接続とメンテナンスが必要です。
b) と c) に対処している限り、接続が切断され続けても問題ありません。短いバッチで処理できるようにアプリケーション プロトコルを設計してください。そのため、ファイルをアップロードする場合は、小さなブロックを送信していることと、アプリケーション プロトコルが途中で壊れた転送を再開できることを確認してください。2 GB の転送を 99% 処理して、接続を失い、最初からやり直す必要はありません。
これを機能させるには、接続自体の寿命を超えてクライアントの接続の論理状態を維持できる、ある種のクライアント セッション状態キャッシュがサーバーに必要です。最初から、特定のセッションに複数の個別の接続が含まれることを期待するように設計します。セッション状態には何らかのタイムアウトが必要になる可能性があるため、クライアントが長時間離れた場合、サーバー上のリソースを消費し続けることはありませんが、正直なところ、単に状態をディスクに保存した後に状態を保存する場合にすぎません。しばらく。
要約すると、トランスポートの選択は問題ではないと思います。少なくとも最初は TCP を使用します。本当に重要なのは、サーバー上でクライアントのセッション状態を管理し、クライアントが定期的に接続および切断するという事実に対処できることです。
于 2010-11-15T08:25:56.723 に答える
0
よくわからない場合は、TCP を使用する必要があります。1 つには、IP をサポートするすべてのネットワーク スタックの一部であることは確実です。「Reliable UDP」はすぐにサポートされることはめったにないため、クライアントのために追加のサポート作業が必要になります。
于 2010-11-14T20:52:42.980 に答える