新しいプロコトル思いついたんやが (23ﾚｽ)
上下前次1-新
1: 2024/06/26(水)20:25 ID:F9kMnufU(1/4) AAS
概要：
ネットワーク層のプロコトルであり、接続IDを用いて事前にプロコトルの宣言と、経路制御を行い、ヘッダ情報を大幅に省略することでパケットのサイズを小さくし、より大容量かつ長期の接続を効率よく行える。
2: 2024/06/26(水)20:26 ID:F9kMnufU(2/4) AAS
接続確立のためのプロコトル：
【接続フロー】
１，接続元(ホストA)から通信規則・経路宣言パケット(以下経路宣言)を接続先(ホストB)へ送信する。
経路宣言は、接続ID、接続元と接続先のIP、相互のポート番号、使用するプロコトル、そして使用する共通鍵を公開鍵で暗号化したもの、自身のホスト証明書及び電子署名を記載する。
２，経路上の機器はパケットを転送しつつ、必要な情報と接続IDを保持しする。各機器が保持するこれを経路情報と呼ぶ。
また、接続ＩＤのコリジョンを検出した場合、転送を止め、パケットが来た反対方向にエラーメッセージを送信し、経路上の機器及び送信元へ接続ＩＤの無効化を伝える。無効化された場合、送信元は新たな接続ＩＤで１からやり直す。
３，接続先(ホストB)へ経路宣言が届いたら、ホストBは内容を記録する。
相互に通信を行わない場合接続承認パケットを送信し、６へ。
相互に通信を行う場合接続日接続関係を入れ替え、１と同じ様に接続元(ホストB)から接続先(ホストB)へ経路宣言を送信する。
省6
3: 2024/06/26(水)20:26 ID:F9kMnufU(3/4) AAS
接続確立後の通信プロコトル：
各通信経路の機器が、パケットの接続IDをもとにパケットを転送していく。その他細かいところはより上位層で実装
【パケットの中身】
ヘッダ情報は接続IDのみで構成される。データ部分には、接続時に受け渡しした共通鍵で暗号化したデータと、その電子署名が記載される。
・通信制御は事前に接続IDと経路情報の組み合わせを通信経路に保持する機器が持つため、他のプロコトルに頼らなくてよい。
・それ以外のプロコトルについても、事前に宣言が行われているため個々のパケットで明記しなくてもデコードが可能
4: 2024/06/26(水)20:26 ID:F9kMnufU(4/4) AAS
質問や詰めの甘いところへの指摘、感想、批評等自由に意見をください。思いつく限り懸念材料は詰めたつもりなので、具体的にここの意見が欲しいって言うのはないですけど、しょせん高１の基本情報に毛が生えた程度の知識なんで見落としは多いと思います。
セキュリティ、ソフトウェア、ハードウェア、ネットワーク、アルゴリズム等の点からの批評、感想、指摘、改善案、追加案などをください！！
5(1): 2024/06/27(木)19:17 ID:??? AAS
TCPすらしならなそう
6: 2024/06/27(木)21:24 ID:K83gmZnc(1) AAS
>>5
TCPくらいは知ってるよ。というか安全な接続の確立のためにかなり参考にさせてもらってるさ。
でもTCPはヘッダ情報削減できないでしょ？
7: 2024/06/28(金)12:41 ID:??? AAS
君もできてない
8(1): 2024/06/28(金)18:05 ID:??? AAS
synやackすら知らなさそう
9: 2024/06/29(土)01:49 ID:b4U8iFdy(1) AAS
>>8
どう読んだらそういう解釈になるんだろう。
大容量データをフラグメント化して送る際、全体でみるとヘッダ重複するから無駄に多くなるよね。
先にヘッダ情報共有しておいて一意のID振っておけば一つ一つのパケットにはヘッダをほとんど記述せずで通信できるんじゃないのかな
そうできれば何パーセントかパケットサイズ小さく済むよね
そのためにはTCP的な接続フローで相互接続を確立する必要があるよね
という割と単純な話のつもりなのだが
10: 2024/06/29(土)10:24 ID:??? AAS
そのフローすら知らないんだろうね君
11(1): 2024/06/30(日)12:07 ID:??? AAS
ルーターやスイッチを殺す気か…？
12(1): 2024/06/30(日)21:24 ID:??? AAS
tcp/ipが設計された意図を知らないでヘッダーガーとか流石に草
世の中が全て専用線ならidすら不要だが、ならばなぜidを振ろうと思うのか？
13: 2024/07/01(月)10:18 ID:pg35xEfZ(1/2) AAS
>>11
それは一理あると思う．．
ただ、経路上の機器は、あるIDのパケットが来たときどのノードに転送するか、さえ記憶できればいいから、最悪機器をアップグレードすれば実現できると予想してる。そこは試算と実験結果からの必要スペック次第かな。
14: 2024/07/01(月)10:35 ID:pg35xEfZ(2/2) AAS
>>12
接続確立時はパケットをどこへ転送するかわからないからIPも使うよ。ただ、その時にIDと転送先のノードの組み合わせを記憶すれば、特定のＩＤのパケットが来たときに転送を行えるでしょう。
接続先と接続元とプロコトルの三つの組み合わせ毎に、仮想的な専用線を、接続時作り上げる＆終了時に解消する、というイメージかな
質問に対する回答としては、どの仮想専用線を利用してるかを識別するために必要だから。
15: 2024/07/01(月)18:27 ID:??? AAS
UDPでも使ってろよ
16: 2024/07/01(月)18:29 ID:??? AAS
ちなみにUDPを拡張してデータ保証する通信ソフトを富士通が発明していた
17: 2024/07/02(火)03:55 ID:5ptWW6rY(1) AAS
UDPとかSCTPとも異なるよ。このプロコトル自体別にパリティビットとかその辺の４層はぶっちゃけどうでもよくて、単に経路情報の共有のために接続に近いことが必要なだけで。
図解しないとわかりにくいかな．．．
18: 2024/07/03(水)05:03 ID:??? AAS
全然わかってなくて草
自信があるならこんなとこで喚かずにrfc書くべき。俺の考えた最強プロトコルとか厨二病は要らん。
802.3のEthernetのところだけ読んでても良くこんなもの思いつくなと感心する。
長い研究の果てにosi の概念が構築されてるのに、都合の良いところだけ摘んで経路制御も出来ないプロトコルとか誰得
19(1): 2024/07/05(金)19:46 ID:??? AAS
画像ﾘﾝｸ[jpg]:i.imgur.com
すぐに2500P+2500Pが手に入ります。
20: 2024/07/05(金)20:06 ID:??? AAS
>>19
もう皆も知ってるが
上下前次1-新書関写板覧索設栞歴
あと 3 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.270s*