0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ステージ1課題解読 2023/9/23~2023/10/8プロジェクト

Last updated at Posted at 2023-09-25

1.はじめに

メインの記録はこちら
課題についての理解を深めるため

2.課題

クライアントがサーバに接続する形式のチャットメッセンジャーサービスを作成します。
サーバはバックグラウンドで稼働し、一方でクライアントはCLIを通じてサーバに接続します。
接続が確立された後、クライアントはメッセージを入力してサーバに送り、そのメッセージはサーバに接続している他の全てのクライアントにも配信されます。

解読

client.py(クライアント), server.py(サーバ)のファイルを作る。
server.pyを先に起動させる。(起動したら動き続ける)
client.pyを起動させTCP形式で接続を確立させる。(複数でも可)
クライアントがメッセージを入力してから、UDP形式でサーバにメッセージを送信させる。
サーバーがメッセージを受け取ったら、他の全てのクライアントにUDP形式でメッセージを配信させる。

3.機能要件

・サーバをCLIで起動し、バックグラウンドで着信接続を待ち受ける。
→ サーバから起動させないとクライアントを起動させても意味ないよ。(チャットサービス自体が停止している)
・サーバとクライアントは、UDPネットワークソケットを使ってメッセージのやり取りをする。
・メッセージ送信時、サーバとクライアントは一度に最大で4096バイトのメッセージを処理します。
→ bufsize = 4096
・セッションが開始される際には、クライアントはユーザにユーザー名を入力させる。
・メッセージの送信プロトコル
メッセージの最初の1バイト"usernamelen"は、ユーザ名の全バイトサイズを示す。
→最大で255バイトになる。
サーバは、はじめの"usernamelen"バイトを読み、送信者のユーザ名を特定する。
その後のバイトは送信される実際のメッセージ。
この情報はサーバとクライアントによって自由に使用され、ユーザ名の表示や保存が可能。
stack = [message, usernamelen]
pop()して情報を読み取るイメージかな
・バイトデータはUTF-8でエンコードおよびデコードされる。
・サーバにはリレーシステムが組み込まれている。
現在接続中の全てのクライアントの情報を一時的にメモリ上に保存する。
新しいメッセージがサーバに届くと、そのメッセージは現在接続中の全クライアントにリレーされます。→リレー?
・クライアントは、何回か連続で失敗するか、しばらくメッセージを送信していない場合、自動的にリレーシステムから削除されます。
→TCPと違い、UDPはコネクションレスであるため、各クライアントの最後のメッセージ送信時刻を追跡する必要がある。
→例えば、3時間以上連絡なかったら自動的にログアウトにする形かな

4.非機能要件

・チャットメッセージングシステムは、リアルタイムのデータの優先度が信頼できるデータよりも高いとされている。
→TCPよりUDPが適している
・システムは、毎秒最低で10,000パケットの送信をサポートする必要がある。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?