RFC817 日本語訳
0817 Modularity and efficiency in protocol implementation. D.D. Clark. July 1982. (Format: TXT=45931 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC: 817
RFC: 817
MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION
プロトコル実装におけるモジュール方式AND効率
David D. Clark
MIT Laboratory for Computer Science
Computer Systems and Communications Group
July, 1982
デヴィッドD.クラークMITコンピュータサイエンス研究所コンピュータシステムズとコミュニケーションは1982年7月に分類されます。
1. Introduction
1. 序論
Many protocol implementers have made the unpleasant discovery that
多くのプロトコルimplementersが不快な発見をそれにしました。
their packages do not run quite as fast as they had hoped. The blame
それらのパッケージは全く望んでいたほど速く動きません。 非難
for this widely observed problem has been attributed to a variety of
これが、問題が結果と考えられたのを広く観測した、様々
causes, ranging from details in the design of the protocol to the
引き起こして、プロトコルのデザインにおける詳細から変化します。
underlying structure of the host operating system. This RFC will
ホスト・オペレーティング・システムの構造の基礎となります。 このRFCはそうするでしょう。
discuss some of the commonly encountered reasons why protocol
理由が議定書を作る一般的に遭遇した理由のいくつかについて議論してください。
implementations seem to run slowly.
実装はゆっくり動くように思えます。
Experience suggests that one of the most important factors in
経験は、最も重要なものの1つが計算に入れるのを示します。
determining the performance of an implementation is the manner in which
実装の性能を決定するのが、中の方法である、どれ
that implementation is modularized and integrated into the host
その実装は、ホストとmodularizedされて、統合されます。
operating system. For this reason, it is useful to discuss the question
オペレーティングシステム。 この理由に、問題について議論するのは役に立ちます。
of how an implementation is structured at the same time that we consider
実装が私たちが考えるのと同時にどう構造化されるかについて
how it will perform. In fact, this RFC will argue that modularity is
それはどう働くだろうか。 事実上、このRFCは、モジュール方式がそうであると主張するでしょう。
one of the chief villains in attempting to obtain good performance, so
したがって、望ましい市場成果を得るのを試みることにおける張本人のひとり
that the designer is faced with a delicate and inevitable tradeoff
デザイナーはデリケートで必然の見返りに直面しています。
between good structure and good performance. Further, the single factor
良い構造と望ましい市場成果の間で。 さらに、シングルは因数分解します。
which most strongly determines how well this conflict can be resolved is
どれが、この闘争をどれくらいよく解決できるかを最も強く決定するかあります。
not the protocol but the operating system.
2
プロトコルではなく、オペレーティングシステム。 2
2. Efficiency Considerations
2. 効率問題
There are many aspects to efficiency. One aspect is sending data
効率への多くの局面があります。 1つの局面がデータを送ります。
at minimum transmission cost, which is a critical aspect of common
最小のトランスミッション費用では、一般的のきわどい局面はどれですか?
carrier communications, if not in local area network communications.
搬送通信どんなローカル・エリア・ネットワークコミュニケーションでもそうしないなら。
Another aspect is sending data at a high rate, which may not be possible
どれがもう一つの側面が高価でデータを送るのが可能でないかもしれませんか?
at all if the net is very slow, but which may be the one central design
ネットがまさしくそのである、全く、遅くなりなさい、ただし、1つの主要なデザインがどれであるかもしれませんか?
constraint when taking advantage of a local net with high raw bandwidth.
高い生の帯域幅に伴うローカルのネットを利用するときの規制。
The final consideration is doing the above with minimum expenditure of
考慮が最小の支出がある上記をしている決勝
computer resources. This last may be necessary to achieve high speed,
コンピュータリソース。 これが、最後に高速を達成するのに必要であるかもしれません。
but in the case of the slow net may be important only in that the
遅いネットの場合では、それだけで重要であるかもしれません。
resources used up, for example cpu cycles, are costly or otherwise
使いきられたリソース(例えば、cpuサイクル)は、高価であるか、またはそうではありません。
needed. It is worth pointing out that these different goals often
必要。 それからこれらの異なった目標をしばしば指す価値があります。
conflict; for example it is often possible to trade off efficient use of
闘争してください。 例えば、それは効率的な使用で取り引きするのにおいてしばしば可能です。
the computer against efficient use of the network. Thus, there may be
ネットワークの効率的な使用に対するコンピュータ。 したがって、あるかもしれません。
no such thing as a successful general purpose protocol implementation.
うまくいっている汎用のプロトコル実装のようなものでない。
The simplest measure of performance is throughput, measured in bits
最も簡単な成績測定基準はビットで測定されたスループットです。
per second. It is worth doing a few simple computations in order to get
1秒単位で。 得るためにいくつかの簡単な計算をする価値があります。
a feeling for the magnitude of the problems involved. Assume that data
かかわった問題の大きさに関する感じ。 そのデータを仮定してください。
is being sent from one machine to another in packets of 576 bytes, the
576のパケットで1台のマシンから別のものに送るのは、バイトです。
maximum generally acceptable internet packet size. Allowing for header
最大の一般に許容できるインターネットパケットサイズ。 ヘッダーを考慮します。
overhead, this packet size permits 4288 bits in each packet. If a
頭上では、このパケットサイズは4288ビット各パケットの入るのを許します。 aです。
useful throughput of 10,000 bits per second is desired, then a data
1万のbpsの役に立つスループットは望まれていて、その時はデータです。
bearing packet must leave the sending host about every 430 milliseconds,
ベアリングパケットは430ミリセカンド毎に関して送付ホストを置き去りにしなければなりません。
a little over two per second. This is clearly not difficult to achieve.
1秒あたり2余り。 これは達成するのが明確に難しくはありません。
However, if one wishes to achieve 100 kilobits per second throughput,
3
しかしながら、3人が2番目のスループットあたり100のキロビットを達成したいなら
the packet must leave the host every 43 milliseconds, and to achieve one
パケットが43人のミリセカンド毎をホストに残さなければならない、1つを達成します。
megabit per second, which is not at all unreasonable on a high-speed
1秒あたりのメガビット。(そのメガビットはaで高速な状態で全く無理ではありません)。
local net, the packets must be spaced no more than 4.3 milliseconds.
ローカルのネット、パケットを4.3ミリセカンド未満と同じくらい区切らなければなりません。
These latter numbers are a slightly more alarming goal for which to
これらの後者の数がわずかに驚くべきな目標である、どれ
set one's sights. Many operating systems take a substantial fraction of
人の目標を設定してください。 オペレーティングシステムがかなりの断片で取る多く
a millisecond just to service an interrupt. If the protocol has been
まさしく中断を修理するミリセカンド。 プロトコルがあったなら
structured as a process, it is necessary to go through a process
プロセスとして構造化されていて、プロセスを通るのが必要です。
scheduling before the protocol code can even begin to run. If any piece
プロトコルコードの前のスケジューリングは稼働し始めることさえできます。 どんな断片です。
of a protocol package or its data must be fetched from disk, real time
プロトコルでは、ディスク、リアルタイムでからパッケージかそのデータをとって来なければなりません。
delays of between 30 to 100 milliseconds can be expected. If the
間の遅れは30〜100ミリセカンドと同じくらい予想できます。予想されます。 the
protocol must compete for cpu resources with other processes of the
プロトコルはcpuリソースのために他のプロセスと競争しなければなりません。
system, it may be necessary to wait a scheduling quantum before the
システム、以前スケジューリング量子を待つのが必要であるかもしれません。
protocol can run. Many systems have a scheduling quantum of 100
プロトコルは稼働できます。 多くのシステムには、100のスケジューリング量子があります。
milliseconds or more. Considering these sorts of numbers, it becomes
ミリセカンドか以上。 これらの種類の数を考える場合、それはなります。
immediately clear that the protocol must be fitted into the operating
すぐに、作動にプロトコルに合わなければならないのが明確です。
system in a thorough and effective manner if any like reasonable
もしあればa徹底的で効果的な方法によるシステムが好きである、妥当
throughput is to be achieved.
スループットは達成されることです。
There is one obvious conclusion immediately suggested by even this
すぐにこれによってさえ示された1つの明白な結論があります。
simple analysis. Except in very special circumstances, when many
簡単な分析。 非常に特別な事情、いつを除いて、多くであるか。
packets are being processed at once, the cost of processing a packet is
パケットはすぐに処理される予定であり、パケットを処理する費用はそうです。
dominated by factors, such as cpu scheduling, which are independent of
cpuスケジューリングなどの要素によって支配されていて、独立者はどれのものですか?
the packet size. This suggests two general rules which any
パケットサイズ。 これが、2一般がどれを統治するかを示す、いくらか。
implementation ought to obey. First, send data in large packets.
実装は従うべきです。 まず最初に、大きいパケットでデータを送ってください。
Obviously, if processing time per packet is a constant, then throughput
そして、明らかにスループット1パケットあたりの処理時間が定数であるなら
will be directly proportional to the packet size. Second, never send an
4
パケットサイズに正比例するでしょう。 2番目に、4を決して送らないでください。
unneeded packet. Unneeded packets use up just as many resources as a
不要なパケット。 不要なパケットはaとちょうど同じくらい多くのリソースを使いきります。
packet full of data, but perform no useful function. RFC 813, "Window
どんな役に立つ機能も実行しないのを除いたデータでいっぱいのパケット。 RFC813、「窓」
and Acknowledgement Strategy in TCP", discusses one aspect of reducing
「TCPのAcknowledgement Strategy」、減少の1つの局面について議論します。
the number of packets sent per useful data byte. This document will
パケットの数は1役に立つデータ・バイト単位で発信しました。 このドキュメントはそうするでしょう。
mention other attacks on the same problem.
同じ問題に対する他の攻撃について言及してください。
The above analysis suggests that there are two main parts to the
上の分析は、2つの主部があるのを示します。
problem of achieving good protocol performance. The first has to do
良いプロトコル性能を達成するという問題。 1番目はしなければなりません。
with how the protocol implementation is integrated into the host
プロトコル実装がどうホストと統合されるかで
operating system. The second has to do with how the protocol package
オペレーティングシステム。 2番目はどのようにと関係があるか、プロトコルパッケージ
itself is organized internally. This document will consider each of
それ自体、内部的に組織化されます。 意志がそれぞれを考えるこのドキュメント
these topics in turn.
これらの話題、順番に。
3. The Protocol vs. the Operating System
3. プロトコル対オペレーティングシステム
There are normally three reasonable ways in which to add a protocol
通常、プロトコルを加える3つの合理的な方法があります。
to an operating system. The protocol can be in a process that is
オペレーティングシステムに。 プロトコルがプロセスにあることができます。
provided by the operating system, or it can be part of the kernel of the
そうすることができるなら、カーネルの一部になってください。
operating system itself, or it can be put in a separate communications
それ自体、またはそれがオペレーティングシステムであることができることは別々のコミュニケーションを入れます。
processor or front end machine. This decision is strongly influenced by
プロセッサかフロントエンドマシン。 この決定は強く影響を及ぼされます。
details of hardware architecture and operating system design; each of
ハードウェアアーキテクチャとオペレーティングシステムデザインの詳細。 それぞれ
these three approaches has its own advantages and disadvantages.
これらの3つのアプローチには、それ自身の利点と損失があります。
The "process" is the abstraction which most operating systems use
「プロセス」はほとんどのオペレーティングシステムが使用する抽象化です。
to provide the execution environment for user programs. A very simple
ユーザ・プログラムAに実行環境を非常に簡単な状態で提供するために
path for implementing a protocol is to obtain a process from the
プロトコルを実装するための経路はプロセスを得ることになっています。
operating system and implement the protocol to run in it.
そして、オペレーティングシステム、プロトコルを実装して、それに立候補してください。
Superficially, this approach has a number of advantages. Since
5
表面的に、このアプローチには、多くの利点があります。 5以来
modifications to the kernel are not required, the job can be done by
カーネルへの変更を必要としないで、仕事ですることができます。
someone who is not an expert in the kernel structure. Since it is often
カーネル構造の専門家でないだれか。 しばしばそれがそうであるので
impossible to find somebody who is experienced both in the structure of
構造で両方の、経験されるだれかを見つけるのは不可能です。
the operating system and the structure of the protocol, this path, from
オペレーティングシステムプロトコルの構造、この経路
a management point of view, is often extremely appealing. Unfortunately,
管理観点はしばしば非常に魅力的です。 残念ながら
putting a protocol in a process has a number of disadvantages, related
プロセスにプロトコルを入れるのにおいて、関係づけられて、多くの損失があります。
to both structure and performance. First, as was discussed above,
構造と性能の両方に。 上で最初に、議論したように
process scheduling can be a significant source of real-time delay.
プロセススケジューリングはリアルタイムの遅れの重要な源であるかもしれません。
There is not only the actual cost of going through the scheduler, but
しかし、スケジューラを通る実費しかありません。
the problem that the operating system may not have the right sort of
オペレーティングシステムはちょっと権利がないかもしれないという問題
priority tools to bring the process into execution quickly whenever
急速にプロセスを実行に運び込む優先権ツール、いつ
there is work to be done.
やるべき仕事があります。
Structurally, the difficulty with putting a protocol in a process
構造的に、aを置く困難はプロセスで議定書を作ります。
is that the protocol may be providing services, for example support of
プロトコルはサービス、例えばサポートを提供しているかもしれません。
data streams, which are normally obtained by going to special kernel
データ・ストリーム。(通常、そのデータ・ストリームは、特別なカーネルに行くことによって、得られます)。
entry points. Depending on the generality of the operating system, it
エントリーは指します。 オペレーティングシステムの一般性による、それ
may be impossible to take a program which is accustomed to reading
読書に慣れているプログラムを取るのは不可能であるかもしれません。
through a kernel entry point, and redirect it so it is reading the data
カーネルエントリーで、指してください、そして、データを読んでいるためにそれを向け直してください。
from a process. The most extreme example of this problem occurs when
プロセスから。 この問題の最も極端な例が現れる、いつ
implementing server telnet. In almost all systems, the device handler
サーバtelnetを実装します。 システム、ほとんどすべてのデバイス操作者で
for the locally attached teletypes is located inside the kernel, and
そして局所的に添付のテレタイプがカーネルの中に位置しているので。
programs read and write from their teletype by making kernel calls. If
プログラムは、それらのテレタイプからカーネル電話をかけることによって、読んで、書きます。 if
server telnet is implemented in a process, it is then necessary to take
サーバtelnetはプロセスで実装されて、次に、取るのが必要です。
the data streams provided by server telnet and somehow get them back
データ・ストリームは、サーバtelnetで提供して、どうにかそれらを取り戻します。
down inside the kernel so that they mimic the interface provided by
彼らが提供されたインタフェースをまねるように、カーネルの中にダウンしてください。
local teletypes. It is usually the case that special kernel
6
地方のテレタイプ。 それ、通常ケースはその特別なカーネル6です。
modification is necessary to achieve this structure, which somewhat
変更がこの構造を達成するのに必要である、どれ、いくらか。
defeats the benefit of having removed the protocol from the kernel in
有の利益がカーネルからのプロトコルを取り除いた敗北
the first place.
1位。
Clearly, then, there are advantages to putting the protocol package
そして、明確に、プロトコルパッケージを置く利点があります。
in the kernel. Structurally, it is reasonable to view the network as a
カーネルで。 構造的に、ネットワークをaであるとみなすのは妥当です。
device, and device drivers are traditionally contained in the kernel.
デバイス、およびデバイスドライバは伝統的にそうです。カーネルでは、含まれています。
Presumably, the problems associated with process scheduling can be
おそらく、プロセススケジューリングに関連している問題はそうであることができます。
sidesteped, at least to a certain extent, by placing the code inside the
コードを中に置くことによって、少なくともある程度までsidestepedしました。
kernel. And it is obviously easier to make the server telnet channels
カーネル。 そして、サーバtelnetチャンネルを作るのは明らかにより簡単です。
mimic the local teletype channels if they are both realized in the same
彼らが同じくらいでともに実感されるなら、ローカルのテレタイプチャンネルをまねてください。
level in the kernel.
カーネルにおけるレベル。
However, implementation of protocols in the kernel has its own set
しかしながら、カーネルにおけるプロトコルの実装で、それ自身のものを設定します。
of pitfalls. First, network protocols have a characteristic which is
落とし穴について。 まず最初に、ネットワーク・プロトコルには、そうする特性があります。
shared by almost no other device: they require rather complex actions
ほとんどどんな対向機器でも、共有されません: 彼らはかなり複雑な動きを必要とします。
to be performed as a result of a timeout. The problem with this
タイムアウトの結果、実行されるために。 これに関する問題
requirement is that the kernel often has no facility by which a program
要件はカーネルには施設が全くどのaプログラムでしばしばあるというわけではないかということです。
can be brought into execution as a result of the timer event. What is
タイマイベントの結果、実行に持って来ることができます。 何がありますか?
really needed, of course, is a special sort of process inside the
本当にもちろん必要であるのは、特殊活字のプロセス内部です。
kernel. Most systems lack this mechanism. Failing that, the only
カーネル。 ほとんどのシステムがこのメカニズムを欠いています。 それに失敗する唯一
execution mechanism available is to run at interrupt time.
利用可能な実行メカニズムは中断時に稼働することです。
There are substantial drawbacks to implementing a protocol to run
実行するプロトコルを実装することへのかなりの欠点があります。
at interrupt time. First, the actions performed may be somewhat complex
中断時に。 まず最初に、実行された動きはいくらか複雑であるかもしれません。
and time consuming, compared to the maximum amount of time that the
時間がかかる、最大の時間とそれを比較します。
operating system is prepared to spend servicing an interrupt. Problems
オペレーティングシステムは中断を修理しながら費やすように準備されます。 問題
can arise if interrupts are masked for too long. This is particularly
7
中断があまりに長い間マスクをかけられるなら、起こることができます。 これは特に7です。
bad when running as a result of a clock interrupt, which can imply that
時計割込みの結果、稼働していると、悪いです。割込みはそれを含意できます。
the clock interrupt is masked. Second, the environment provided by an
時計割込みは仮面です。 2番目に、環境は提供しました。
interrupt handler is usually extremely primitive compared to the
比べて、通常、割り込みハンドラは非常に原始的です。
environment of a process. There are usually a variety of system
プロセスの環境。 通常、さまざまなシステムがあります。
facilities which are unavailable while running in an interrupt handler.
割り込みハンドラへ駆け込んでいる間入手できない施設。
The most important of these is the ability to suspend execution pending
これらで最も重要であるのは、未定の状態で執行を中止する能力です。
the arrival of some event or message. It is a cardinal rule of almost
何らかのイベントかメッセージの到着。 それがそう、枢機卿はほとんど判決を下します。
every known operating system that one must not invoke the scheduler
1がそうしなければならないあらゆる知られているオペレーティングシステムがスケジューラを呼び出すというわけではありません。
while running in an interrupt handler. Thus, the programmer who is
割り込みハンドラへ駆け込んでいる間。 その結果、そうするプログラマ
forced to implement all or part of his protocol package as an interrupt
彼のプロトコルパッケージのすべてか一部が中断として実装させられます。
handler must be the best sort of expert in the operating system
操作者はオペレーティングシステムでちょっと専門であることで最も良いに違いありません。
involved, and must be prepared for development sessions filled with
セッションが満ちた開発のためにかかわって、用意しなければならなくなってください。
obscure bugs which crash not just the protocol package but the entire
プロトコルパッケージだけではなく、全体も墜落させる不鮮明なバグ
operating system.
オペレーティングシステム。
A final problem with processing at interrupt time is that the
中断時の処理に関する最終的な問題はそれです。
system scheduler has no control over the percentage of system time used
システムスケジューラで、システム時間の割合のコントロールを全く使用しません。
by the protocol handler. If a large number of packets arrive, from a
プロトコル操作者で。 多くのパケットがaから到着するなら
foreign host that is either malfunctioning or fast, all of the time may
誤動作しているか、または速い異種宿主、現代のすべてはそうするかもしれません。
be spent in the interrupt handler, effectively killing the system.
事実上、システムをだめにして、割り込みハンドラに費やされてください。
There are other problems associated with putting protocols into an
そこ、交際した他の問題はプロトコルを入れています。
operating system kernel. The simplest problem often encountered is that
オペレーティングシステムカーネル。 しばしば行きあたられる中で最も簡単な問題はそれです。
the kernel address space is simply too small to hold the piece of code
カーネルアドレス空間は単にコードの断片を保持できないくらい小さいです。
in question. This is a rather artificial sort of problem, but it is a
問題。 これはかなり人工の種類の問題ですが、それはaです。
severe problem none the less in many machines. It is an appallingly
厳しい問題、やはり、多くのマシンで。 それがそうである、恐ろしさ
unpleasant experience to do an implementation with the knowledge that
8
知識がある実装にその8をする不愉快な出来事
for every byte of new feature put in one must find some other byte of
入れられたある他のバイトを見つけなければならないあらゆるバイトの新機能のために
old feature to throw out. It is hopeless to expect an effective and
放り出す古い特徴。 そしてそれが予想するために絶望的である、有効である。
general implementation under this kind of constraint. Another problem
この種類の規制での一般的な実装。 別の問題
is that the protocol package, once it is thoroughly entwined in the
それでいったん徹底的にからませられると、それはプロトコルパッケージです。
operating system, may need to be redone every time the operating system
オペレーティングシステム、毎回やり直されるのが必要であるかもしれない、オペレーティングシステム
changes. If the protocol and the operating system are not maintained by
変化。 プロトコルとオペレーティングシステムが維持されないなら
the same group, this makes maintenance of the protocol package a
同じように、分類してください、そして、これはプロトコルパッケージのメインテナンスをaにします。
perpetual headache.
永久の頭痛。
The third option for protocol implementation is to take the
プロトコル実装のための3番目のオプションは取ることです。
protocol package and move it outside the machine entirely, on to a
aにパッケージについて議定書の中で述べてください、そして、それをマシンの外に完全に動かしてください。
separate processor dedicated to this kind of task. Such a machine is
この種類に関するタスクに捧げられたプロセッサを切り離してください。 そのようなマシンはそうです。
often described as a communications processor or a front-end processor.
しばしばコミュニケーションプロセッサかフロントエンドプロセッサとして記述されています。
There are several advantages to this approach. First, the operating
このアプローチのいくつかの利点があります。 最初に、作動
system on the communications processor can be tailored for precisely
正確にプロセッサを仕立てることができるコミュニケーションのシステム
this kind of task. This makes the job of implementation much easier.
この種類に関するタスク。 これで、実装の仕事ははるかに簡単になります。
Second, one does not need to redo the task for every machine to which
2番目、ものがあらゆるマシンのためのタスクを手直しする必要はない、どれ
the protocol is to be added. It may be possible to reuse the same
プロトコルは加えられることです。 それは同じように再利用するのにおいて可能であるかもしれません。
front-end machine on different host computers. Since the task need not
異なったホストコンピュータの上のフロントエンドマシン。 以来、タスクはそうする必要はありません。
be done as many times, one might hope that more attention could be paid
人が、何回も、より多くの注意を向けることができたことを望むかもしれないので、してください。
to doing it right. Given a careful implementation in an environment
まさしくそれをするのに。 環境における慎重な実装を与えました。
which is optimized for this kind of task, the resulting package should
この種類に関するタスク、結果として起こるパッケージのために最適化されるものはそうするべきです。
turn out to be very efficient. Unfortunately, there are also problems
非常に効率的であると判明してください。 残念ながら、問題もあります。
with this approach. There is, of course, a financial problem associated
これと共にアプローチしてください。 もちろん、関連づけられた経済問題があります。
with buying an additional computer. In many cases, this is not a
追加コンピュータを買うのに。 多くの場合、これはaではありません。
problem at all since the cost is negligible compared to what the
費用が取るにたらないので、全く問題はことと比較されました。
programmer would cost to do the job in the mainframe itself. More
9
プログラマは、メインフレーム自体で仕事するのをかかるでしょう。 より多くの9
fundamentally, the communications processor approach does not completely
基本的に、コミュニケーションプロセッサアプローチは完全にそうするというわけではありません。
sidestep any of the problems raised above. The reason is that the
上に提起された問題のいずれもかわしてください。 理由はそれです。
communications processor, since it is a separate machine, must be
それが別々のマシンであり、あるに違いないコミュニケーションプロセッサ
attached to the mainframe by some mechanism. Whatever that mechanism,
何らかのメカニズムでメインフレームに付きました。 そのメカニズムが何であっても
code is required in the mainframe to deal with it. It can be argued
コードが、それに対処するのにメインフレームで必要です。 それについて論争できます。
that the program to deal with the communications processor is simpler
コミュニケーションプロセッサに対処するプログラムは、より簡単です。
than the program to implement the entire protocol package. Even if that
全体のプロトコルパッケージを実装するプログラムより。 それ
is so, the communications processor interface package is still a
したがって、それでも、コミュニケーションプロセッサインタフェースパッケージがaであることです。
protocol in nature, with all of the same structural problems. Thus, all
同じ構造上の問題その結果、すべてのすべてで現実に議定書を作ってください。
of the issues raised above must still be faced. In addition to those
必須の上でまだ提起されていた問題では、面してください。 それらに加えて
problems, there are some other, more subtle problems associated with an
問題であり、ある、ある他の交際したより微妙な問題
outboard implementation of a protocol. We will return to these problems
プロトコルの船外の実装。 私たちはこれらの問題に戻るつもりです。
later.
後で。
There is a way of attaching a communications processor to a
コミュニケーションプロセッサをaに取り付ける方法があります。
mainframe host which sidesteps all of the mainframe implementation
メインフレーム実装のすべてをかわすメインフレーム・ホスト
problems, which is to use some preexisting interface on the host machine
ホスト・マシンの上のいくつかの先在のインタフェースを使用することである問題
as the port by which a communications processor is attached. This
コミュニケーションプロセッサが付属しているポートとして。 これ
strategy is often used as a last stage of desperation when the software
ソフトウェアであるときに、戦略は最後のステージの自暴自棄としてしばしば使用されます。
on the host computer is so intractable that it cannot be changed in any
オンである、ホストコンピュータが非常に手に負えないので、いずれでもそれを変えることができません。
way. Unfortunately, it is almost inevitably the case that all of the
ずっと。 残念ながら、それがほぼ必然的にそうである、ケース、そんなにすべて。
available interfaces are totally unsuitable for this purpose, so the
したがって、利用可能なインタフェースはこのために完全に不適当です。
result is unsatisfactory at best. The most common way in which this
結果はせいぜい不十分です。 最も一般的な入口、どれ、これ
form of attachment occurs is when a network connection is being used to
付属のフォームが起こる、ネットワーク接続がいつまで使用されているかということです。
mimic local teletypes. In this case, the front-end processor can be
地方のテレタイプをまねてください。 この場合、フロントエンドプロセッサはそうであることができます。
attached to the mainframe by simply providing a number of wires out of
単に多くのワイヤを提供するメインフレームに付きます。
the front-end processor, each corresponding to a connection, which are
10
フロントエンドプロセッサ、接続との各文通。(その文通は10です)。
plugged into teletype ports on the mainframe computer. (Because of the
メインフレーム・コンピュータでテレタイプポートのプラグを差し込みました。 (
appearance of the physical configuration which results from this
これから生じる物理的な構成の外観
arrangement, Michael Padlipsky has described this as the "milking
アレンジメント、マイケルPadlipskyは「乳をしぼる」としてこれを記述しました。
machine" approach to computer networking.) This strategy solves the
コンピュータのネットワーク化への「マシン」アプローチ。) この戦略は解決します。
immediate problem of providing remote access to a host, but it is
しかし、ホスト、それに遠隔アクセスを提供する手近な問題はそうです。
extremely inflexible. The channels being provided to the host are
非常に融通がききません。 ホストに提供されるチャンネルはそうです。
restricted by the host software to one purpose only, remote login. It
ホストソフトウェアによって1つの目的の唯一の、そして、リモートなログインに制限されます。 それ
is impossible to use them for any other purpose, such as file transfer
ファイル転送などのいかなる他の目的にもそれらを使用するのは不可能です。
or sending mail, so the host is integrated into the network environment
または、メールを送って、したがって、ホストはネットワーク環境と統合されます。
in an extremely limited and inflexible manner. If this is the best that
非常に制限されて堅い方法で。 これが最も良い、それ
can be done, then it should be tolerated. Otherwise, implementors
することができて、次に、それを許容するべきです。 そうでなければ、作成者
should be strongly encouraged to take a more flexible approach.
よりフレキシブルなアプローチを取るよう強く奨励されるべきです。
4. Protocol Layering
4. プロトコルレイヤリング
The previous discussion suggested that there was a decision to be
前の議論は、それが決定がいたと示唆しました。
made as to where a protocol ought to be implemented. In fact, the
プロトコルが実装されるべきであるところに関して作られています。 事実上
decision is much more complicated than that, for the goal is not to
決定は目標へのそれよりはるかに複雑にされます。
implement a single protocol, but to implement a whole family of protocol
しかし、ただ一つのプロトコルを実装して、プロトコルの家族全員を実装してください。
layers, starting with a device driver or local network driver at the
デバイスドライバか企業内情報通信網のドライバーをきっかけに、層にします。
bottom, then IP and TCP, and eventually reaching the application
下部と、次に、IPと、TCPと、結局、アプリケーションに達すること。
specific protocol, such as Telnet, FTP and SMTP on the top. Clearly,
先端のTelnetや、FTPやSMTPなどの特定のプロトコル。 明確に
the bottommost of these layers is somewhere within the kernel, since the
これらの層の最低部が以来、カーネルの中のどこかにあります。
physical device driver for the net is almost inevitably located there.
ネットのためのフィジカル・デバイスドライバーはそこにほぼ必然的に位置しています。
Equally clearly, the top layers of this package, which provide the user
等しく、明確に、先端はこのパッケージを層にします(ユーザを提供します)。
his ability to perform the remote login function or to send mail, are
リモート・ログイン機能を実行するか、またはメールを送る彼の能力
not entirely contained within the kernel. Thus, the question is not
11
カーネルの中に完全に含まれていません。 したがって、質問は11ではありません。
whether the protocol family shall be inside or outside the kernel, but
しかし、カーネルの中、または、カーネルの外にプロトコルファミリーがあるものとして
how it shall be sliced in two between that part inside and that part
それはその部分内部とその部分の間の2でどう切られるものとするか。
outside.
外。
Since protocols come nicely layered, an obvious proposal is that
プロトコルがうまく層にされた状態で来るので、明白な提案はそれです。
one of the layer interfaces should be the point at which the inside and
そして層のインタフェースの1つがポイントであるべきである、どれ、内部。
outside components are sliced apart. Most systems have been implemented
外のコンポーネントは離れて切られます。 ほとんどのシステムが導入されました。
in this way, and many have been made to work quite effectively. One
これでは、道、および多くがそうです。かなり力を発揮させられます。 1つ
obvious place to slice is at the upper interface of TCP. Since TCP
切る明白な場所がTCPの上側のインタフェースにあります。 TCP以来
provides a bidirectional byte stream, which is somewhat similar to the
a双方向のバイト・ストリームを供給します。(それは、いくらか同様です)。
I/O facility provided by most operating systems, it is possible to make
ほとんどのオペレーティングシステムで入出力装置を提供して、それは作るのにおいて可能です。
the interface to TCP almost mimic the interface to other existing
TCPへのインタフェースは他の存在にインタフェースをほとんどまねます。
devices. Except in the matter of opening a connection, and dealing with
デバイス。 接続を開く問題に関して除いて、対処します。
peculiar failures, the software using TCP need not know that it is a
独特の失敗であり、TCPを使用するソフトウェアは、それがaであることを知る必要はありません。
network connection, rather than a local I/O stream that is providing the
提供されている地方の入出力ストリームよりむしろ接続をネットワークでつないでください。
communications function. This approach does put TCP inside the kernel,
コミュニケーションは機能します。 このアプローチはカーネルの中にTCPを置きます。
which raises all the problems addressed above. It also raises the
上で扱われたすべての問題を提起します。 また、それは上げます。
problem that the interface to the IP layer can, if the programmer is not
プログラマがそうでなく、IP層へのインタフェースがそうすることができるという問題
careful, become excessively buried inside the kernel. It must be
慎重であることで、カーネルの中に過度に埋まるようになってください。 それはそうであるに違いありません。
remembered that things other than TCP are expected to run on top of IP.
TCP以外のものがIPの上で稼働すると予想されたのを覚えていました。
The IP interface must be made accessible, even if TCP sits on top of it
TCPがそれの上に座ってもIPインタフェースをアクセスしやすくしなければなりません。
inside the kernel.
カーネルの中で。
Another obvious place to slice is above Telnet. The advantage of
Telnetの上に切る別の明白な場所はあります。 利点
slicing above Telnet is that it solves the problem of having remote
Telnetの上の切るのはリモートな状態で有の問題を解決するということです。
login channels emulate local teletype channels. The disadvantage of
ログインチャンネルはローカルのテレタイプチャンネルをエミュレートします。 不都合
putting Telnet into the kernel is that the amount of code which has now
12
カーネルにTelnetを入れて、それは現在12を持っているコードの量ですか?
been included there is getting remarkably large. In some early
含まれていて、著しく大きくなるのがあります。 いくつか、早期
implementations, the size of the network package, when one includes
実装、ネットワークパッケージ、いつに関するサイズはあるインクルードであるか。
protocols at the level of Telnet, rivals the size of the rest of the
Telnetのレベルにおけるプロトコル、残りのサイズのライバル
supervisor. This leads to vague feelings that all is not right.
監督。 これは権利ではなく、あいまいな気持ちに通じます。
Any attempt to slice through a lower layer boundary, for example
例えば、下層境界を切るように進むどんな試み
between internet and TCP, reveals one fundamental problem. The TCP
インターネットとTCP、啓示の間で、ある基本的な問題。 TCP
layer, as well as the IP layer, performs a demultiplexing function on
IP層と同様に、層は逆多重化機能を実行します。
incoming datagrams. Until the TCP header has been examined, it is not
受信データグラムTCPヘッダーが調べられたとき、それは初めて、調べられていました。
possible to know for which user the packet is ultimately destined.
パケットが結局どのユーザに関して運命づけられているかを知るのにおいて、可能です。
Therefore, if TCP, as a whole, is moved outside the kernel, it is
したがって、TCPがカーネルの外で全体で動かされるなら、それは動かされます。
necessary to create one separate process called the TCP process, which
TCPプロセスと呼ばれる1つの別々のプロセスを作成するのに必要である、どれ
performs the TCP multiplexing function, and probably all of the rest of
TCPマルチプレクシング機能、およびたぶん残りのすべてを実行します。
TCP processing as well. This means that incoming data destined for a
また、TCP処理。 これは、受信データがaのために運命づけられたことを意味します。
user process involves not just a scheduling of the user process, but
しかし、ユーザ・プロセスはまさしくユーザ・プロセスのどんなスケジューリングも伴いません。
scheduling the TCP process first.
最初に、TCPプロセスの計画をします。
This suggests an alternative structuring strategy which slices
これは切られる戦略を構造化する代替手段を示します。
through the protocols, not along an established layer boundary, but
しかし確立した層の境界ではなく、プロトコルを通して。
along a functional boundary having to do with demultiplexing. In this
逆多重化と関係がある機能的境界に沿って。 これで
approach, certain parts of IP and certain parts of TCP are placed in the
アプローチ、IPのある部分、およびTCPのある部分は置かれます。
kernel. The amount of code placed there is sufficient so that when an
カーネル。 そこに置かれたコードの量が十分なそう、それ、いつ
incoming datagram arrives, it is possible to know for which process that
受信データグラムは届いて、どのプロセスでそれを知るかは可能です。
datagram is ultimately destined. The datagram is then routed directly
データグラムは結局、運命づけられています。 そして、データグラムは直接発送されます。
to the final process, where additional IP and TCP processing is
決勝に、追加IPとTCP処理が処理するところで処理してください。
performed on it. This removes from the kernel any requirement for timer
それに実行されます。 これはカーネルからタイマのためのどんな要件も取り除きます。
based actions, since they can be done by the process provided by the
13
13時までに提供されたプロセスでそれらができて以来のベースの動き
user. This structure has the additional advantage of reducing the
ユーザ。 この構造には、減少する追加利点があります。
amount of code required in the kernel, so that it is suitable for
カーネルで必要であるコードの量、それが適当であるそう
systems where kernel space is at a premium. The RFC 814, titled "Names,
プレミアムにはカーネルスペースがあるシステム。 「名前」と題をつけられたRFC814
Addresses, Ports, and Routes," discusses this rather orthogonal slicing
「アドレス、Ports、およびRoutes」はこのかなり直交した切ることについて議論します。
strategy in more detail.
その他の詳細の戦略。
A related discussion of protocol layering and multiplexing can be
プロトコルレイヤリングとマルチプレクシングの関連する議論はそうであることができます。
found in Cohen and Postel [1].
コーエンとポステル[1]では、設立します。
5. Breaking Down the Barriers
5. バリアを破壊します。
In fact, the implementor should be sensitive to the possibility of
事実上、作成者は可能性に敏感であるべきです。
even more peculiar slicing strategies in dividing up the various
様々に分割することにおけるさらに独特の切る戦略
protocol layers between the kernel and the one or more user processes.
カーネルと1つ以上のユーザ・プロセスの間の層について議定書の中で述べてください。
The result of the strategy proposed above was that part of TCP should
上で提案された戦略の結果はTCPの一部がそうするべきであるということでした。
execute in the process of the user. In other words, instead of having
ユーザの途中に、実行します。 有の代わりに言い換えれば。
one TCP process for the system, there is one TCP process per connection.
1TCPがシステムのために処理して、1接続あたり1つのTCPプロセスがあります。
Given this architecture, it is not longer necessary to imagine that all
このアーキテクチャを考えて、それがすべてであると想像するのは必要な状態で、より長くはありません。
of the TCPs are identical. One TCP could be optimized for high
TCPsは同じです。 高値のために1TCPを最適化できました。
throughput applications, such as file transfer. Another TCP could be
ファイル転送などのスループット応用。 別のTCPはそうであるかもしれません。
optimized for small low delay applications such as Telnet. In fact, it
Telnetなどの小さい低い遅れアプリケーションのために、最適化されています。 事実上、それ
would be possible to produce a TCP which was somewhat integrated with
いくらか統合されたTCPを生産するのにおいて、可能でしょう。
the Telnet or FTP on top of it. Such an integration is extremely
それの上のTelnetかFTP。 そのような統合がそうである、非常に。
important, for it can lead to a kind of efficiency which more
重要である、それは一種の効率でどれにさらに通じることができるか。
traditional structures are incapable of producing. Earlier, this paper
伝統的な構造は生産できません。 より早いこの紙
pointed out that one of the important rules to achieving efficiency was
指摘されて、重要1つが効率を増すのに統治されるのがありました。
to send the minimum number of packets for a given amount of data. The
与えられたデータ量のためにパケットの最小の数を送るために。 The
idea of protocol layering interacts very strongly (and poorly) with this
14
プロトコルレイヤリングの考えは非常に強いこと(不十分である)にこの14と対話します。
goal, because independent layers have independent ideas about when
いつ頃に関して独立している層には独自の考えがあるか目標
packets should be sent, and unless these layers can somehow be brought
パケットを送るべきです、そして、これらの層がどうにかそうすることができないなら、持って来てください。
into cooperation, additional packets will flow. The best example of
協力に、追加パケットは流れるでしょう。 例を負かします。
this is the operation of server telnet in a character at a time remote
これは時にリモートなキャラクタで、サーバtelnetの操作です。
echo mode on top of TCP. When a packet containing a character arrives
TCPの上でモードを反映してください。 キャラクタを含むパケットが到着する場合
at a server host, each layer has a different response to that packet.
サーバー・ホストでは、各層はそのパケットに異なった応答を持っています。
TCP has an obligation to acknowledge the packet. Either server telnet
TCPには、パケットを承認する義務があります。 どちらかのサーバtelnet
or the application layer above has an obligation to echo the character
または、上の応用層には、キャラクタの言葉を繰り返す義務があります。
received in the packet. If the character is a Telnet control sequence,
パケットでは、受け取られています。 キャラクタがTelnetであるなら、系列を制御してください。
then Telnet has additional actions which it must perform in response to
に対応して次に、Telnetにはそれが実行しなければならない追加動作がある。
the packet. The result of this, in most implementations, is that
パケット。 ほとんどの実装におけるこの結果はそれです。
several packets are sent back in response to the one arriving packet.
いくつかのパケットが1つの到着パケットに対応して返送されます。
Combining all of these return messages into one packet is important for
1つのパケットへのこれらのリターンメッセージのすべてが重要である結合
several reasons. First, of course, it reduces the number of packets
数個が推論します。 もちろん、まず最初に、それはパケットの数を減少させます。
being sent over the net, which directly reduces the charges incurred for
ネットの上に送って、どれが直接被られた充電を下げるか。
many common carrier tariff structures. Second, it reduces the number of
多くの運輸業者関税構造。 2番目に、それは数を減少させます。
scheduling actions which will occur inside both hosts, which, as was
両方のホストの中に起こる動作の計画をする、どれ、あったか。
discussed above, is extremely important in improving throughput.
議論された上はスループットを改良するのにおいて非常に重要です。
The way to achieve this goal of packet sharing is to break down the
パケットが共有されるというこの目標を達成する方法に失敗することになっています。
barrier between the layers of the protocols, in a very restrained and
そしてプロトコルであって、aでの非常に抑制にされるのの層の間のバリア。
careful manner, so that a limited amount of information can leak across
限られた情報量が横切って漏れることができる慎重な態度
the barrier to enable one layer to optimize its behavior with respect to
1つの層が振舞いを最適化するのを可能にするバリア
the desires of the layers above and below it. For example, it would
それとそれの下の層の願望。 例えば、それはそうするでしょう。
represent an improvement if TCP, when it received a packet, could ask
それがパケットを受けたときにはTCPであるなら改良を表してください、そして、尋ねることができました。
the layer above whether or not it would be worth pausing for a few
いくつかのために止まる価値があるだろうかどうかの上の層
milliseconds before sending an acknowledgement in order to see if the
15
15であるなら見るために承認を送る前のミリセカンド
upper layer would have any outgoing data to send. Dallying before
上側の層には、送るどんな発信データもあるでしょう。 以前、ふざけます。
sending the acknowledgement produces precisely the right sort of
承認を送ると、正確に権利はちょっと生産されます。
optimization if the client of TCP is server Telnet. However, dallying
TCPのクライアントであるなら、最適化はサーバTelnetです。 しかしながら、ふざけること。
before sending an acknowledgement is absolutely unacceptable if TCP is
TCPが容認できないなら承認を送るのが絶対に容認できなくなる前に
being used for file transfer, for in file transfer there is almost never
ファイル転送には、ほとんどないので、ファイル転送に使用されます。
data flowing in the reverse direction, and the delay in sending the
反対の方向、および発信の遅れで流れるデータ
acknowledgement probably translates directly into a delay in obtaining
承認はたぶん直接入手の遅れに翻訳されます。
the next packets. Thus, TCP must know a little about the layers above
次のパケット。 したがって、TCPは上の層に関して少し知らなければなりません。
it to adjust its performance as needed.
必要に応じて性能を調整するそれ。
It would be possible to imagine a general purpose TCP which was
一般的な目的がそうするTCPであると想像するのは可能でしょう。
equipped with all sorts of special mechanisms by which it would query
それが質問されるいろいろな特別なメカニズムを備えています。
the layer above and modify its behavior accordingly. In the structures
それに従って、振舞いを上で層にして、変更してください。 構造で
suggested above, in which there is not one but several TCPs, the TCP can
上に示されて、1つがあるのではなく、どれが数個のTCPsがあるかで、TCPはそうすることができます。
simply be modified so that it produces the correct behavior as a matter
件として正しい振舞いを起こすように、単に変更されてください。
of course. This structure has the disadvantage that there will be
もちろん。 この構造には、ある難点があります。
several implementations of TCP existing on a single machine, which can
単一マシンの上に存在するTCPのいくつかの実装。(その実装はそうすることができます)。
mean more maintenance headaches if a problem is found where TCP needs to
TCPが、必要があるところで問題が見つけられるなら、より多くのメインテナンス頭痛を意味します。
be changed. However, it is probably the case that each of the TCPs will
変えてください。 しかしながら、それぞれのTCPsがそうするのは、たぶん事実です。
be substantially simpler than the general purpose TCP which would
汎用のそうするTCPより実質的に簡単であってください。
otherwise have been built. There are some experimental projects
さもなければ、建てられてください、そうした。 いくつかの実験的な計画があります。
currently under way which suggest that this approach may make designing
現在、道の下では、どれが、これにアプローチするのを示すかは設計をするかもしれません。
of a TCP, or almost any other layer, substantially easier, so that the
実質的により簡単なTCP、またはほとんどいかなる他の層
total effort involved in bringing up a complete package is actually less
完全なパッケージを持って来るのにかかわる総取り組みは実際により少ないです。
if this approach is followed. This approach is by no means generally
このアプローチが続かれているなら。 このアプローチが決してそうである、一般に。
accepted, but deserves some consideration.
16
受け入れますが、何らかの考慮に値します。 16
The general conclusion to be drawn from this sort of consideration
この種類の考慮から得られるべき一般的な結論
is that a layer boundary has both a benefit and a penalty. A visible
境界が持っているそのa層は利益と刑罰の両方ですか? 目に見えるA
layer boundary, with a well specified interface, provides a form of
境界がよく指定されたインタフェースにフォームを提供する層
isolation between two layers which allows one to be changed with the
2つの層の間の1つが交換されるのを許容する分離
confidence that the other one will not stop working as a result.
もう片方がその結果仕事を中止しないという信用。
However, a firm layer boundary almost inevitably leads to inefficient
しかしながら、堅い層の境界はほぼ必然的に効率の悪く導きます。
operation. This can easily be seen by analogy with other aspects of
操作。 他の局面への類推で容易にこれを見ることができます。
operating systems. Consider, for example, file systems. A typical
オペレーティングシステム考えてください、そして、例えば、典型的にシステムAをファイルしてください。
operating system provides a file system, which is a highly abstracted
オペレーティングシステムはファイルシステムを提供します。(それは、非常に抜き取られたaです)。
representation of a disk. The interface is highly formalized, and
ディスクの表現。 そしてインタフェースが非常に正式にされる。
presumed to be highly stable. This makes it very easy for naive users
あえて非常に安定していました。 これで、それはナイーブなユーザにとって非常に簡単になります。
to have access to disks without having to write a great deal of
書く必要はなくてディスクに近づく手段を持っている、多く
software. The existence of a file system is clearly beneficial. On the
ソフトウェア。 ファイルシステムの存在は明確に有益です。 オン
other hand, it is clear that the restricted interface to a file system
手で他であり、制限がファイルシステムに接続するのは、明確です。
almost inevitably leads to inefficiency. If the interface is organized
ほぼ必然的に、非能率に通じます。 インタフェースが組織化されているなら
as a sequential read and write of bytes, then there will be people who
a連続する、バイトを読んで、主題にして書いてください、そして、だれを住ませるかそしてそこでは、ことでしょう。
wish to do high throughput transfers who cannot achieve their goal. If
目的を果たすことができない高生産性転送をすることを願ってください。 if
the interface is a virtual memory interface, then other users will
インタフェースが仮想記憶インタフェースである、次に、他のユーザはそうするでしょう。
regret the necessity of building a byte stream interface on top of the
上バイト・ストリームインタフェースを造るという必要性を後悔してください。
memory mapped file. The most objectionable inefficiency results when a
メモリはファイルを写像しました。 aであるときに、最も好ましくない非能率は結果として生じます。
highly sophisticated package, such as a data base management package,
データベースの管理パッケージなどの非常に高性能のパッケージ
must be built on top of an existing operating system. Almost
既存のオペレーティングシステムの上に建てなければなりません。 ほとんど
inevitably, the implementors of the database system attempt to reject
必然的に、拒絶しますデータベース・システムの作成者が、試みる。
the file system and obtain direct access to the disks. They have
システムをファイルしてください、そして、直接アクセスをディスクに得てください。 それらはそうしました。
sacrificed modularity for efficiency.
効率のためにモジュール方式を犠牲にしました。
The same conflict appears in networking, in a rather extreme form.
17
同じ闘争はネットワーク、かなり極端なフォームに載っています。 17
The concept of a protocol is still unknown and frightening to most naive
プロトコルの概念は、それでも、未知と大部分にナイーブな状態で怯えさせることです。
programmers. The idea that they might have to implement a protocol, or
プログラマ。 または彼らがプロトコルを実装しなければならないかもしれないという考え。
even part of a protocol, as part of some application package, is a
何らかのアプリケーションパッケージの一部として、プロトコルの一部さえaです。
dreadful thought. And thus there is great pressure to hide the function
恐ろしい考え。 そして、その結果、機能を隠すかなりの圧力があります。
of the net behind a very hard barrier. On the other hand, the kind of
非常に固いバリアの後ろのネットについて。 他方では、種類
inefficiency which results from this is a particularly undesirable sort
これから生じる非能率は特に望ましくない種類です。
of inefficiency, for it shows up, among other things, in increasing the
非能率は、現れるので、特に、そして、中で増加すること。
cost of the communications resource used up to achieve the application
アプリケーションを達成するのに使いきられたコミュニケーションリソースの費用
goal. In cases where one must pay for one's communications costs, they
目標。 人のコミュニケーションコストの代価を払わなければならない場合でそれら
usually turn out to be the dominant cost within the system. Thus, doing
システムの中の優位な費用であろうとしている通常回転。 その結果、
an excessively good job of packaging up the protocols in an inflexible
中のプロトコルへのパッケージの過度に良い仕事、堅さ
manner has a direct impact on increasing the cost of the critical
方法には、批判的費用を上げるとき、直接的な衝撃があります。
resource within the system. This is a dilemma which will probably only
システムの中のリソース。 これはたぶんそうするジレンマ専用です。
be solved when programmers become somewhat less alarmed about protocols,
プログラマがプロトコルがいくらか心配でなくなったら、解決されてください。
so that they are willing to weave a certain amount of protocol structure
彼らが、ある量のプロトコル構造を織っても構わないと思っているように
into their application program, much as application programs today weave
それらのアプリケーション・プログラムに、アプリケーション・プログラムとしての多くが今日、機を織ります。
parts of database management systems into the structure of their
構造へのデータベース管理システムが離れている、それら
application program.
アプリケーション・プログラム。
An extreme example of putting the protocol package behind a firm
プロトコルパッケージを会社の過去のこととする極端な例
layer boundary occurs when the protocol package is relegated to a front-
プロトコルパッケージが前部に左遷されるとき、層の境界は起こります。
end processor. In this case the interface to the protocol is some other
プロセッサを終わらせてください。 この場合プロトコルへのインタフェースがそうである、ある他の
protocol. It is difficult to imagine how to build close cooperation
議定書を作ってください。 厳密な協力を組み込む方法を想像するのは難しいです。
between layers when they are that far separated. Realistically, one of
層の間に、それらがいつそんなに遠いかは分離しました。 現実的である、1
the prices which must be associated with an implementation so physically
それほど物理的に実現に関連しなければならない価格
modularized is that the performance will suffer as a result. Of course,
modularizedされて、それは意志がその結果受ける性能ですか? もちろん
a separate processor for protocols could be very closely integrated into
18
非常に密接にプロトコルのための別々のプロセッサを18と統合できました。
the mainframe architecture, with interprocessor co-ordination signals,
interprocessorコーディネーション信号があるメインフレーム構造
shared memory, and similar features. Such a physical modularity might
共有メモリ、および同様の特徴。 そのような物理的なモジュール方式はそうするかもしれません。
work very well, but there is little documented experience with this
非常によく働きなさい、ただし、この経験は少ししか記録されません。
closely coupled architecture for protocol support.
プロトコルサポートのための密接に結合した構造。
6. Efficiency of Protocol Processing
6. プロトコル処理の効率
To this point, this document has considered how a protocol package
この位まで、このドキュメントは、どのようにがプロトコルパッケージであるかと考えました。
should be broken into modules, and how those modules should be
モジュールと、それらのモジュールがどうそうあるべきであるかに壊されるべきです。
distributed between free standing machines, the operating system kernel,
無料の地位のマシン、オペレーティングシステムカーネルの間に分配されています。
and one or more user processes. It is now time to consider the other
そして、1人以上のユーザが処理します。 現在もうもう片方を考えるべき時間です。
half of the efficiency question, which is what can be done to speed the
半分の効率(疾走するためにできることである)は質問されます。
execution of those programs that actually implement the protocols. We
実際にプロトコルを実行するそれらのプログラムの実行。 私たち
will make some specific observations about TCP and IP, and then conclude
TCPとIPに関していくつかの特定の観測をして、次に、結論を下すでしょう。
with a few generalities.
いくつかの一般性で。
IP is a simple protocol, especially with respect to the processing
IPは特に処理に関する簡単なプロトコルです。
of normal packets, so it should be easy to get it to perform
したがって、正常なパケットでは、実行させるのは簡単であるはずです。
efficiently. The only area of any complexity related to actual packet
効率的に。 実際のパケットに関連するどんな複雑さの唯一の領域
processing has to do with fragmentation and reassembly. The reader is
処理は断片化と再アセンブリと関係があります。 読者はそうです。
referred to RFC 815, titled "IP Datagram Reassembly Algorithms", for
「IPデータグラムReassemblyアルゴリズム」と題をつけられたRFC815は参照されます。
specific consideration of this point.
このポイントの特定の考慮。
Most costs in the IP layer come from table look up functions, as
IP層のほとんどのコストが機能でテーブル外観から来ます。
opposed to packet processing functions. An outgoing packet requires two
パケット処理機能に反対されます。 出発しているパケットは2を必要とします。
translation functions to be performed. The internet address must be
翻訳は、実行されるために機能します。 インターネットアドレスはそうであるに違いありません。
translated to a target gateway, and a gateway address must be translated
翻訳されて、目標ゲートウェイ、およびアドレスがそうしなければならないゲートウェイに移されてください。
to a local network number (if the host is attached to more than one
19
企業内情報通信網番号、(ホストは1つ19以上に付けられています。
network). It is easy to build a simple implementation of these table
ネットワーク) これらのテーブルの簡単な実現を組み込むのは簡単です。
look up functions that in fact performs very poorly. The programmer
事実上、それが非常に不十分に実行する機能を見上げてください。 プログラマ
should keep in mind that there may be as many as a thousand network
最大1,000ネットワークがあるかもしれないのを覚えておくべきです。
numbers in a typical configuration. Linear searching of a thousand
典型的な構成の数。 1,000を直線的な探すこと
entry table on every packet is extremely unsuitable. In fact, it may be
あらゆるパケットに関するエントリテーブルは非常に不適当です。 事実上、それはそうです。
worth asking TCP to cache a hint for each connection, which can be
各接続のためにヒントをキャッシュするようにTCPに頼む価値があるので、どれがあることができますか?
handed down to IP each time a packet is sent, to try to avoid the
避けるトライにパケットを送るたびにIPまで手渡されます。
overhead of a table look up.
テーブルのオーバーヘッドは見上げます。
TCP is a more complex protocol, and presents many more
TCPは、より複雑なプロトコルであり、ずっと多くを提示します。
opportunities for getting things wrong. There is one area which is
ものを間違う機会。 そうする1つの領域があります。
generally accepted as causing noticeable and substantial overhead as
一般に、引き起こすとしてめぼしくて、頭上で実質的であると受け入れます。
part of TCP processing. This is computation of the checksum. It would
TCP処理の一部。 これはチェックサムの計算です。 それはそうするでしょう。
be nice if this cost could be avoided somehow, but the idea of an end-
この費用を避けることができるなら良くいてください、どうにか終わりの考えだけ
to-end checksum is absolutely central to the functioning of TCP. No
終わりまでのチェックサムはTCPの機能に絶対に主要です。 いいえ
host implementor should think of omitting the validation of a checksum
ホスト作成者は、チェックサムの合法化を省略することを考えるべきです。
on incoming data.
受信データに関して。
Various clever tricks have been used to try to minimize the cost of
様々な賢明なトリックは費用を最小にするトライに使用されました。
computing the checksum. If it is possible to add additional microcoded
チェックサムを計算します。 加えるのが可能である、追加、microcoded
instructions to the machine, a checksum instruction is the most obvious
マシンへの指示であり、チェックサム指示は最も明白です。
candidate. Since computing the checksum involves picking up every byte
候補。 チェックサムを計算するのが、あらゆるバイトを拾うことを伴うので
of the segment and examining it, it is possible to combine the operation
セグメントとそれを調べるのにおいて、操作を結合するのは可能です。
of computing the checksum with the operation of copying the segment from
セグメントをコピーする操作があるチェックサムを計算します。
one location to another. Since a number of data copies are probably
別のものへの1つの位置。 多くのデータコピーがたぶんそうであるので
already required as part of the processing structure, this kind of
処理構造の一部として既に必要であって、これほど親切です。
sharing might conceivably pay off if it didn't cause too much trouble to
20
20に問題を起こし過ぎるというわけではないなら、共有は多分うまく行くでしょうに。
the modularity of the program. Finally, computation of the checksum
プログラムのモジュール方式。 最終的にチェックサムの計算
seems to be one place where careful attention to the details of the
慎重であるところの1つの場所であるように思える、詳細に関する注意
algorithm used can make a drastic difference in the throughput of the
アルゴリズムはスループットの缶の造のa抜本的な差を使用しました。
program. The Multics system provides one of the best case studies of
プログラムを作ってください。 システムが最も良いケーススタディの1つを提供するMultics
this, since Multics is about as poorly organized to perform this
これMulticsがこれを実行するのが同じくらいおよそ不十分に組織化されて、
function as any machine implementing TCP. Multics is a 36-bit word
TCPを実行するどんなマシンとしての機能。 Multicsは36ビットの単語です。
machine, with four 9-bit bytes per word. The eight-bit bytes of a TCP
4で、1単語あたりの9ビットのバイトを機械加工してください。 TCPの8ビットのバイト
segment are laid down packed in memory, ignoring word boundaries. This
語境界を無視して、セグメントはメモリに詰まっていた状態で定められます。 これ
means that when it is necessary to pick up the data as a set of 16-bit
16ビットのセットとしてデータを受信するのが必要であるときに、それを意味します。
units for the purpose of adding them to compute checksums, horrible
ものすごい状態でチェックサムを計算するためにそれらを加える目的のためのユニット
masking and shifting is required for each 16-bit value. An early
マスキングと移行がそれぞれの16ビットの値に必要です。 早期
version of a program using this strategy required 6 milliseconds to
戦略が6人のミリセカンドを必要としたプログラムがこれを使用するバージョン
checksum a 576-byte segment. Obviously, at this point, checksum
チェックサムのa576バイトのセグメント。 明らかと、ここ、チェックサム
computation was becoming the central bottleneck to throughput. A more
計算はスループットへの中央のボトルネックになっていました。 より多くのmore
careful recoding of this algorithm reduced the checksum processing time
このアルゴリズムの慎重な再コード化はチェックサム処理時間を短縮しました。
to less than one millisecond. The strategy used was extremely dirty.
1ミリセカンド未満に。 使用される戦略は非常に汚かったです。
It involved adding up carefully selected words of the area in which the
それは、中の領域の慎重に選択された単語にどれを追加するかを伴いました。
data lay, knowing that for those particular words, the 16-bit values
それらの特定の単語、16ビットの値でそれを知っていて、データがありました。
were properly aligned inside the words. Only after the addition had
単語で適切に並べられました。 後だけに、添加はそうしました。
been done were the various sums shifted, and finally added to produce
しているのが、生産する移行して、最終的に加えられた様々な合計であったということです。
the eventual checksum. This kind of highly specialized programming is
最後のチェックサム。 この種類の非常に専門化しているプログラミングはそうです。
probably not acceptable if used everywhere within an operating system.
たぶん許容できませんが、いたる所では、オペレーティングシステムの中で使用されています。
It is clearly appropriate for one highly localized function which can be
それは明確に適切な個人的には非常に局所化されたそうすることができる機能です。
clearly identified as an extreme performance bottleneck.
極端な性能のネックとして明確に特定されています。
Another area of TCP processing which may cause performance problems
性能問題を引き起こすかもしれないTCP処理の別の領域
is the overhead of examining all of the possible flags and options which
21
可能な旗とオプションのすべてを調べるオーバーヘッドはどの21ですか?
occur in each incoming packet. One paper, by Bunch and Day [2], asserts
それぞれの入って来るパケットに起こってください。 紙がBunchとデー[2]で断言する1
that the overhead of packet header processing is actually an important
パケットのヘッダー処理のオーバーヘッドが実際にそうである、重要
limiting factor in throughput computation. Not all measurement
スループット計算の要素を制限します。 すべての測定でない
experiments have tended to support this result. To whatever extent it
実験は、この結果を支持する傾向がありました。 いかなる範囲、もそれ
is true, however, there is an obvious strategy which the implementor
しかしながら、本当に、明白な戦略があるということである、どれ、作成者
ought to use in designing his program. He should build his program to
彼のプログラムを設計する際に使用するべきです。 彼はプログラムを組立てるべきです。
optimize the expected case. It is easy, especially when first designing
予想されたケースを最適化してください。 特に最初に設計するとき、それは簡単です。
a program, to pay equal attention to all of the possible outcomes of
aは可能な結果のすべてに関する有料の等しい注意にプログラムを作ります。
every test. In practice, however, few of these will ever happen. A TCP
あらゆるテスト。 しかしながら、実際には、これらのわずかしか起こらないでしょう。 TCP
should be built on the assumption that the next packet to arrive will
到着する次のパケットがそうするという前提で建てられるべきです。
have absolutely nothing special about it, and will be the next one
それに関して特別なものは何も絶対に持たないでください、そして、次のものでしょう。
expected in the sequence space. One or two tests are sufficient to
系列スペースでは、予想されます。 テストが十分である1か2
determine that the expected set of control flags are on. (The ACK flag
予想されたセットの指揮旗がオンであることを決定してください。 (ACKは弛みます。
should be on; the Push flag may or may not be on. No other flags should
オンであるべきです。 Push旗はオンであるかもしれません。 他のどんな旗もそうするべきではありません。
be on.) One test is sufficient to determine that the sequence number of
オンであってください。) 1つのテストがそれを決定できるくらいの一連番号
the incoming packet is one greater than the last sequence number
入って来るパケットは最後の一連番号よりすばらしい1つです。
received. In almost every case, that will be the actual result. Again,
受け取られている。 ほとんどすべての場合、それは実際の結果になるでしょう。 再び
using the Multics system as an example, failure to optimize the case of
例、ケースを最適化する失敗としてMulticsシステムを使用します。
receiving the expected sequence number had a detectable effect on the
予想された一連番号を受けると、検出可能な影響はオンに与えられました。
performance of the system. The particular problem arose when a number
システムの性能。 数であるときに、特定の問題は起こりました。
of packets arrived at once. TCP attempted to process all of these
パケットはすぐに、到着しました。 TCPは、これらをすべて、処理するのを試みました。
packets before awaking the user. As a result, by the time the last
ユーザを起こす前のパケット。 最終までに結果として
packet arrived, there was a threaded list of packets which had several
パケットは到着して、数個を持っていたパケットの糸を通されたリストがありました。
items on it. When a new packet arrived, the list was searched to find
それの項目。 新しいパケットが到着したとき、リストは掘り出し物として捜されました。
the location into which the packet should be inserted. Obviously, the
パケットが挿入されるべきである位置。 明らかに
list should be searched from highest sequence number to lowest sequence
22
リストは最も高い一連番号から最も低い系列22まで捜されるべきです。
number, because one is expecting to receive a packet which comes after
来るパケットを受けた後のために1つがおめでたの予定であることでの数
those already received. By mistake, the list was searched from front to
ものは既に受信されました。 リストから前で間違って、探されました。
back, starting with the packets with the lowest sequence number. The
最も低い一連番号があるパケットをきっかけに、戻ります。 The
amount of time spent searching this list backwards was easily detectable
後方にこのリストを捜しながら費やされた時間は容易に検出可能でした。
in the metering measurements.
計量測定値で。
Other data structures can be organized to optimize the action which
他のデータ構造が動作を最適化するのを組織化できる、どれ
is normally taken on them. For example, the retransmission queue is
通常、それらの上で取ります。 例えば、再送キューはそうです。
very seldom actually used for retransmission, so it should not be
したがって、実際に「再-トランスミッション」において非常にめったに使用されていなくて、それはそうであるべきではありません。
organized to optimize that action. In fact, it should be organized to
その動作を最適化するのが組織化されます。 事実上、それは組織化されるべきです。
optimized the discarding of things from it when the acknowledgement
承認であるときに、それからものを捨てることを最適化します。
arrives. In many cases, the easiest way to do this is not to save the
到着します。 多くの場合、これをする最も簡単な方法は節約しないことです。
packet at all, but to reconstruct it only if it needs to be
全くパケット、しかし、必要がある場合にだけそれを再建するには、いてください。
retransmitted, starting from the data as it was originally buffered by
それが元々バッファリングされたときデータから始めて、再送されます。
the user.
ユーザ。
There is another generality, at least as important as optimizing
最適化するのと少なくとも同じくらい重要な別の一般性があります。
the common case, which is to avoid copying data any more times than
それ以上の回データをコピーするのを避けることであるよくある例
necessary. One more result from the Multics TCP may prove enlightening
必要。 Multics TCPからのもうひとつの結果が啓蒙的であると判明するかもしれません。
here. Multics takes between two and three milliseconds within the TCP
ここ。 MulticsはTCPの中で2〜3ミリセカンドと同じくらい取ります。
layer to process an incoming packet, depending on its size. For a 576-
サイズによって、層にして、入って来るパケットを処理してください。 576のために
byte packet, the three milliseconds is used up approximately as follows.
バイトパケット、3人のミリセカンドは以下の通りほとんど使いきられます。
One millisecond is used computing the checksum. Six hundred
1人のミリセカンドはチェックサムを計算するのにおいて使用されています。 600
microseconds is spent copying the data. (The data is copied twice, at
マイクロセカンドはデータをコピーするのに費やされます。 (データは二度コピーされます。
.3 milliseconds a copy.) One of those copy operations could correctly
1コピーあたり.3ミリセカンド。) それらのコピー操作の1つは正しくそうすることができました。
be included as part of the checksum cost, since it is done to get the
チェックサム費用の一部として、得るためにそれをするので、含められてください。
data on a known word boundary to optimize the checksum algorithm.
23
チェックサムアルゴリズムを最適化する知られている語境界に関するデータ。 23
However, the copy also performs another necessary transfer at the same
しかしながら、また、コピーは同じくらいで別の必要な転送を実行します。
time. Header processing and packet resequencing takes .7 milliseconds.
時間。 ヘッダー処理とパケット再配列は.7ミリセカンドと同じくらい取ります。
The rest of the time is used in miscellaneous processing, such as
現代の残りは種々雑多な処理に使用されます。
removing packets from the retransmission queue which are acknowledged by
「再-トランスミッション」からのパケットが承認されるものを列に並ばせる取り外し
this packet. Data copying is the second most expensive single operation
このパケット。 データコピーは2番目に高価なただ一つの操作です。
after data checksuming. Some implementations, often because of an
データの後にchecksumingしています。 しばしばいくつかの実現
excessively layered modularity, end up copying the data around a great
過度に層にされたモジュール方式、大物の周りにデータをコピーすることへの終わり
deal. Other implementations end up copying the data because there is no
取扱います。 いいえがあるのでデータをコピーすることへの他の実現終わり
shared memory between processes, and the data must be moved from process
間の共有メモリは処理されます、そして、過程からデータを動かさなければなりません。
to process via a kernel operation. Unless the amount of this activity
カーネル操作で処理するために。 この活動の量
is kept strictly under control, it will quickly become the major
厳密にコントロールの下で保たれて、急速に少佐になるということです。
performance bottleneck.
性能のネック。
7. Conclusions
7. 結論
This document has addressed two aspects of obtaining performance
このドキュメントは性能を得る2つの局面を記述しました。
from a protocol implementation, the way in which the protocol is layered
プロトコル実現、プロトコルが層にされる方法から
and integrated into the operating system, and the way in which the
オペレーティングシステム、および入口とどれを統合するか。
detailed handling of the packet is optimized. It would be nice if one
パケットの詳細な取り扱いは最適化されています。 1であるなら良いでしょう。
or the other of these costs would completely dominate, so that all of
または、これらのコストのもう片方が完全に支配されて、そうがそれである、すべて
one's attention could be concentrated there. Regrettably, this is not
人の注意をそこに集結できました。 残念なことに、これはそうではありません。
so. Depending on the particular sort of traffic one is getting, for
そのように。 交通1の特定の種類に依存するのは、得ることです。
example, whether Telnet one-byte packets or file transfer maximum size
Telnetの1バイトのパケットかファイル転送最大サイズであることの例
packets at maximum speed, one can expect to see one or the other cost
最大におけるパケットは疾走して、人は、1かもう片方の費用を見ると予想できます。
being the major bottleneck to throughput. Most implementors who have
スループットへの主要なボトルネックです。 そうしたほとんどの作成者
studied their programs in an attempt to find out where the time was
研究されて、どこから時間を見つけるか試みにおける彼らのプログラムがありました。
going have reached the unsatisfactory conclusion that it is going
24
行くのはそれが現在の24であるという不満足な結果に達しました。
equally to all parts of their program. With the possible exception of
等しく、彼らのプログラムをすべてに離れさせます。 可能な例外
checksum processing, very few people have ever found that their
チェックサムの処理していて、ほんのわずかな人々が今までにそれを見つけたことがある、彼ら
performance problems were due to a single, horrible bottleneck which
性能問題はaに単一の、そして、ものすごい支払われるべきものがどれを妨害するかということでした。
they could fix by a single stroke of inventive programming. Rather, the
彼らは発明的なプログラミングの1つのストロークで修理するかもしれません。 むしろ
performance was something which was improved by painstaking tuning of
性能は勤勉な調律で改良された何かでした。
the entire program.
全体のプログラム。
Most discussions of protocols begin by introducing the concept of
プロトコルの議論が概念を紹介することによって始まる大部分
layering, which tends to suggest that layering is a fundamentally
レイヤリング。(そのレイヤリングはレイヤリングが基本的にaであると示唆する傾向があります)。
wonderful idea which should be a part of every consideration of
あらゆる考慮の一部であるべきである素晴らしい考え
protocols. In fact, layering is a mixed blessing. Clearly, a layer
プロトコル。 事実上、レイヤリングはありがたいようなありがたくないようなことです。 明確に層
interface is necessary whenever more than one client of a particular
事項のあるクライアントより多くであるときはいつも、インタフェースが必要です。
layer is to be allowed to use that same layer. But an interface,
層はその同じ層を使用するのが許容されることです。 インタフェース
precisely because it is fixed, inevitably leads to a lack of complete
まさにそれが固定されているので、必然的に、先導がaに欠けている、完全
understanding as to what one layer wishes to obtain from another. This
1つの層が別のものから得たがっているものに関して、分かります。 これ
has to lead to inefficiency. Furthermore, layering is a potential snare
非能率に通じるように、持っています。 その上、レイヤリングは潜在的罠です。
in that one is tempted to think that a layer boundary, which was an
1つがそのa層の境界を考えるように誘惑されるので、どれがあったか。
artifact of the specification procedure, is in fact the proper boundary
事実上、仕様手順の人工物は適切な境界です。
to use in modularizing the implementation. Again, in certain cases, an
モジュール化に実現を使用するために。 再びコネあるケース
architected layer must correspond to an implemented layer, precisely so
したがって、architected層は正確に実行された層に対応しなければなりません。
that several clients can have access to that layer in a reasonably
数人のクライアントがaで合理的にその層に近づく手段を持つことができます。
straightforward manner. In other cases, cunning rearrangement of the
正直な態度。 他のケース、ずるい配列換え
implemented module boundaries to match with various functions, such as
様々な機能に合うようにモジュール限界を実行しました。
the demultiplexing of incoming packets, or the sending of asynchronous
入って来るパケットの逆多重化、または非同期の発信
outgoing packets, can lead to unexpected performance improvements
出発しているパケット、予期していなかった性能改良への缶のリード
compared to more traditional implementation strategies. Finally, good
より伝統的な実現戦略と比較されます。 ,
performance is something which is difficult to retrofit onto an existing
25
性能は既存の25に改装するのが何か難しいものです。
program. Since performance is influenced, not just by the fine detail,
プログラムを作ってください。 以来、性能は詳しくない詳細だけによって影響を及ぼされます。
but by the gross structure, it is sometimes the case that in order to
しかし、時々それが総計の構造のそばでは、ケースである、それ
obtain a substantial performance improvement, it is necessary to
かなりの性能改良を得てください、そして、それが必要です。
completely redo the program from the bottom up. This is a great
下からプログラムを完全に手直ししてください。 これは大物です。
disappointment to programmers, especially those doing a protocol
プログラマ、特にプロトコルをするものにおける失望
implementation for the first time. Programmers who are somewhat
初めての実現。 いくらかそうであるプログラマ
inexperienced and unfamiliar with protocols are sufficiently concerned
関係があるので、プロトコルに未経験であって、なじみがないのは、十分、そうです。
with getting their program logically correct that they do not have the
彼らのそうしないのが論理的に正しいプログラムにはある得ること
capacity to think at the same time about the performance of the
性能が同時に考える容量
structure they are building. Only after they have achieved a logically
彼らが建設している構造。 後だけに、彼らはaを論理的に達成しました。
correct program do they discover that they have done so in a way which
正しいプログラム、彼らは、彼らがそう方法でどれをしたかと発見します。
has precluded real performance. Clearly, it is more difficult to design
本当の性能を排除しました。 明確に、それは設計するのが難しいです。
a program thinking from the start about both logical correctness and
そしてともに論理的な正当性に関する始めからのaプログラムの思い。
performance. With time, as implementors as a group learn more about the
性能。 グループが以上を学ぶような作成者としての時間
appropriate structures to use for building protocols, it will be
ビルプロトコルに使用する構造を当ててください、そして、それはあるでしょう。
possible to proceed with an implementation project having more
以上を持っている実現プロジェクトを続けるのにおいて、可能です。
confidence that the structure is rational, that the program will work,
構造が合理的であり、プログラムが動作するという信用
and that the program will work well. Those of us now implementing
そして、プログラムはうまくいくでしょう。 私たちが現在実行するもの
protocols have the privilege of being on the forefront of this learning
プロトコルには、この学習の最先端にある特権があります。
process. It should be no surprise that our programs sometimes suffer
処理してください。 私たちのプログラムに時々苦しむのは、驚きであるべきではありません。
from the uncertainty we bring to bear on them.
26
私たちがそれらの上へ生かす不確実性から。 26
Citations
引用
[1] Cohen and Postel, "On Protocol Multiplexing", Sixth Data
[1] 6番目の「プロトコルマルチプレクシング」のコーエンとポステル、データ
Communications Symposium, ACM/IEEE, November 1979.
コミュニケーションシンポジウム、ACM/IEEE、1979年11月。
[2] Bunch and Day, "Control Structure Overhead in TCP", Trends and
そして[2] 「TCPの制御構造オーバーヘッド」という房と日が傾く。
Applications: Computer Networking, NBS Symposium, May 1980.
アプリケーション: コンピュータのネットワーク化(NBSシンポジウム)は1980がそうするかもしれません。
一覧
スポンサーリンク
