インスタントメッセンジャーのTCPまたはUDPは何が良いですか？

Question

Javaのlangで純粋なソケットを使ってクライアント/サーバーのインスタントメッセンジャーを実装する必要があります。
サーバは多数のクライアントにサービスを提供する必要があり、使用するソケット（TCPまたはUDP）を決定する必要があります。おかげで、コスタ。

Answer 1

TCP

理由：

TCP：「転送されたデータはそのまま残り、それが送信されたのと同じ順序で到着したことを絶対的な保証はあり」

UDP：「送信されたメッセージやパケットがまったく届く保証はありません」あなたのチャットメッセージはおそらく失わたいでしょうhttp://www.diffen.com/difference/TCP_vs_UDP

：

はでより多くを学ぶのか？

を編集してください：「大きなチャットプログラム」に関する部分が欠けていました。私は、TCPサーバーである必要があるチャットプログラムの性質のため、UDPプロトコルでユーザーから送信された実際のテキストコンテンツを想像することはできません。

TCPサーバの最大制限は、同時に65536接続です。その番号を実際に通過する必要がある場合は、現在のサーバーの負荷に応じて適切なサーバーに着信接続を送信するディスパッチャサーバーを作成できます。

Answer 2

メッセージがサーバーに配信されたかどうかをユーザーが知る必要があるかどうかによって異なります。 UDPパケットには固有の肯定応答がありません。クライアントがサーバーにIMメッセージを送信し、そのメッセージが送信中に失われた場合、クライアントまたはサーバーはどちらもそのことを認識しません。

（。短い答えは、「TCPを使う」である...しかし、それはあなた自身のための設計への影響を通じて考える価値がある）

Answer 3

TCPはあなたにインスタントメッセージング中に確かに望ましい信頼性を与えるだろう - あなたをコンバース時にメッセージをドロップすることは望ましくありません。

ただし、グループメッセージングを使用する場合は、mulitcastを使用する可能性があります。そのような場合、UDPはポイントツーマルチポイントを扱うことができるので、UDPは正しいキーオーシーになります。マルチキャストアプリケーションにTCPを使用することは、送信者が複数の受信者の再送信/送信レートを追跡しなければならないので難しいでしょう。 1つの方法として、ポイントツーポイントチャットにTCPを使用し、グループメッセージングにUDPを使用する方法があります。

Answer 4

両方を使用できます。実際のメッセージを交換するには、TCPを使用します（データが失われず、大量のメッセージをストリーミングするなど）（jpegなどが含まれています）UDPは、キューに入れられたメッセージがあるクライアントに短い 'connectNow' UDPの 'connectNow'メッセージは、TCPdisconnectedのクライアントに接続してから移動するように指示します（NotLoggedIn、TCPconnected、TCPdisconnected、LoggedOut）。状態遷移と通常のメッセージ交換イベントを制御します。これはもちろん信頼性が低いため、X秒ごとに 'connectNow'メッセージをN回繰り返すこともできますクライアントが接続するまで。クライアントは、どんな場合でも、毎分X分のポーリングを試みる必要があります。