RFC1324 日本語訳
1324 A Discussion on Computer Network Conferencing. D. Reed. May 1992. (Format: TXT=24988 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Reed Request for Comments: 1324 May 1992
コメントを求めるワーキンググループD.リードの要求をネットワークでつないでください: 1324 1992年5月
A Discussion on Computer Network Conferencing
コンピュータネットワーク会議についての議論
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field.
このメモは、働いているこの分野にかかわるプログラマと他のもののために、より多くの人々をコンピュータConferencing分野で現在の開発を意識するようにして、共通基準があるようにこの仕事を正式にするために何をするべきであるかに関する考えについて提唱することを意図します。 また、それはこのメモがこの分野の長所に関してコンピュータ共同体を刺激して、何らかの役に立つ議論を生成するという意志です。
Introduction
序論
Computer network conferencing is just now starting to grow and take advantage of the modern technology that is available. Although there are some systems which have been around for some time (BRC - Bitnet Relay Chat and IRC - Internet Relay Chat), there has not been any real move to bring them together under a single protocol. This has led to various protocols and different systems coming to life. As these different systems continue to pop up, it is becoming more obvious that there is need of a standard in this area for developers to follow without the need of worrying about protocol clashes.
コンピュータネットワーク会議は、利用可能な現代の技術を、育てて、ちょうど今利用し始めています。 しばらく周囲にあるいくつかのシステム(BRC--Bitnet Relay ChatとIRC--インターネットRelay Chat)がありますが、ただ一つのプロトコルの下でそれらを集めるために、どんな本当の移動もありませんでした。 これは生き返る様々なプロトコルと異系統に通じました。 これらの異系統が、急に現れ続けているのに従って、開発者がプロトコル衝突を心配する必要性なしで続くのは規格の必要がこの領域にあるのが、より明白になっています。
In any implementation of a conferencing program, there are likely to be two main components: (1) a client program or interface which users enter commands into (hereafter referred to as a "client") and 2) a server program which acts as a multiplexor for various clients which connect to it. There are other expectations and requirements for both servers and clients which are mentioned in more detail later.
会議プログラムのどんな実装にも、2つの主なコンポーネントがありそうです: (1) クライアントプログラムかユーザがコマンドを入力するインタフェース(今後「クライアント」と呼ばれる)と1サーバあたり2が)様々なクライアントのためのマルチプレクサーとしてのそれに接続するどの行為をプログラムするか。 さらに詳細に後で言及されるサーバとクライアントの両方のための他の期待と要件があります。
Table of Contents
目次
1.0 Network Conferencing Today........................... 2 1.1 Conferencing in general today........................ 2 1.2 Talk/phone vs. conferencing.......................... 3 1.3 Advantages of realtime network conferencing.......... 3 2.0 Goals for what a protocol should provide............. 4
1.0 今日、会議をネットワークでつないでください… 2 一般に、今日の1.1会議… 2 1.2 会議に対して話すか、または電話をします。 3 リアルタイムでの1.3の利点が会議をネットワークでつなぎます… 3 プロトコルが提供するべきであるものの2.0の目標… 4
Reed [Page 1] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[1ページ]。
2.1 State Information problems........................... 4 2.2 Network barriers..................................... 4 2.3 User needs........................................... 4 2.3.1 User privacy......................................... 4 2.3.2 Realtime Expectations................................ 5 2.4 Message Delivery..................................... 5 2.4.1 Deficiencies in using IP only........................ 5 2.4.2 Flexibility.......................................... 5 2.4.3 Building a flexible transport protocol............... 5 2.5 Network Structure.................................... 5 2.5.1 Size................................................. 5 3.0 Usage................................................ 6 4.0 Setting it up........................................ 6 4.1 Installation......................................... 6 4.2 Controlling growth................................... 7 5.0 Finding the *right* protocol......................... 7 5.1 Name for protocol.................................... 7 5.2 Responsibilities of conference servers............... 7 5.2.1 Message passing...................................... 7 5.2.2 Who is on?........................................... 7 5.2.3 Who is who?.......................................... 8 5.2.4 Conference security.................................. 8 5.2.5 Error reporting...................................... 8 5.2.6 Network Friendliness................................. 8 5.2.7 To ASCII or not to ASCII............................. 8 5.2.8 Queries or messages to a server and replies.......... 9 5.3 Responsibilities of clients.......................... 9 5.3.1 Providing accurate information....................... 9 5.3.2 Client as servers.................................... 9 5.4 How complex should the protocol be?................. 10 5.4.1 User identification................................. 10 5.4.2 Trees and cycles.................................... 10 5.5 Protocol summary.................................... 10 6.0 Security Considerations............................. 10 7.0 Author's Address.................................... 11
2.1 情報問題を述べてください… 4 2.2 バリアをネットワークでつないでください… 4 2.3 ユーザの必要性… 4 2.3 .1 ユーザプライバシー… 4 2.3 .2 リアルタイムで期待… 5 2.4 メッセージ配送… 5 2.4 IPだけを使用することにおける.1の欠乏… 5 2.4 .2の柔軟性… 5 2.4 .3 フレキシブルな輸送を組み込んで、議定書を作ってください… 5 2.5ネットワーク構造… 5 2.5 .1サイズ… 5 3.0用法… 6 4.0 それをセットアップします… 6 4.1インストール… 6 4.2 成長を制御します… 7 *が正しい*であることがわかる5.0は議定書を作ります… 7 5.1 プロトコルにちなんで命名します。 7 会議サーバの5.2の責任… 7 5.2 .1メッセージ・パッシング… 7 5.2 .2 だれがオンですか? 7 5.2 そうする.3、だれですか? 8 5.2 .4 コンファレンスセキュリティ… 8 5.2 .5 誤り報告… 8 5.2 .6 友情をネットワークでつないでください… 8 5.2 .7、ASCIIかどんなASCIIにもそうしません… 8 5.2 サーバと回答への.8の質問かメッセージ… 9 クライアントの5.3の責任… 9 5.3 .1 的確な情報を提供します… 9 5.3 サーバとしての.2クライアント… 9 5.4 プロトコルはどれくらい複雑であるべきですか? 10 5.4 .1ユーザ登録名… 10 5.4 .2木とサイクル… 10 5.5 概要について議定書の中で述べてください… 10 6.0 セキュリティ問題… 10 7.0作者のアドレス… 11
1.0 NETWORK CONFERENCING TODAY
1.0 ネットワーク会議今日
1.1 Conferencing in general today
1.1 一般に、今日の会議
Conferences today are an integral part of the business world in many ways. A conference may be held to reassure staff about company problems (boost moral) or may be held by a few directors in an emergency situation where a carefully considered solution is needed. Conferences also form the cornerstone of workshops held where various groups of people, who attend, are to be briefed on new developments. In nearly all of these situations, there will be a group of 2 or more, where each speaks and listens to others. There exist PABXs and
今日のコンファレンスは様々な意味で業界の不可欠の地域です。 会議が、会社の問題(教訓を高める)に関してスタッフを再保証するために開催されるかもしれないか、または慎重に考えられたソリューションが必要である非常時の状況で数人のディレクターによって行われるかもしれません。 また、コンファレンスは出席する人々の様々なグループが新しい開発に関して事情を知らせられることになっているところで開かれるワークショップの礎石を形成します。 ほとんどこれらの状況のすべてに、2人以上のグループがあるでしょう。(そこでは、それぞれが、他のものを話して、言うことを聞きます)。 そしてPABXsが存在している。
Reed [Page 2] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[2ページ]。
other features of the telephone system which provide for conferencing between people around the globe at a cost effective rate. The only place which really lacks any formal form of conferencing is the internet, although many unofficial conferencing systems already exist, spanning the globe or providing local forums.
費用効率がよいレートで地球の周りの人々の間の会議に備える電話の他の特徴。 本当にどんな正式なフォームの会議も欠いている唯一の場所がインターネットです、多くの非公式の会議システムが既に存在していますが、地球にかかっているか、または地方のフォーラムを提供して。
1.2 Talk/phone vs. conferencing
1.2 話/電話対会議
To provide instantaneous communication between two users on unix and other multiuser systems, interprocess communication is commonly used either over a network or other local methods. The diversity of unix platforms has introduced as many problems as the presence of various operating systems on the net. Commonly, those on Unix based machines are unable to talk to those on VMS or VM machines. The occasion even arises where two Unix hosts are unable to talk to each other due to different talk protocols.
unixと他のマルチユーザ・システムの上で2人のユーザの瞬時に起こっているコミュニケーションを提供するために、プロセス間通信はネットワークか他のローカルのメソッドの上で一般的に使用されます。 unixプラットホームの多様性はネットで様々なオペレーティングシステムの存在と同じくらい多くの問題を紹介しました。 一般的に、Unixのベースのマシンの上のそれらはVMSかVMマシンに関してそれらと話すことができません。 時は2人のUnixホストが異なった話のプロトコルのため互いに話すことができないところに起こりさえします。
1.3 Advantages of realtime computer conferencing
1.3 リアルタイムでコンピュータ会議の利点
By providing a standard for computer conferencing, it should eliminate the problem of who is using what computer. This will mean that someone from a VMS or VM machine can talk with one or more people without having to worry whether their counterpart has an account on a compatible machine for their choice of communication. Electronic mail (email) has already reached this position with most modern mailers on the internet being compliant with RFC822. It is therefore not unreasonable to expect this of realtime conferencing which is to talk as USENet is to email; although of those four (4), only email and news have been covered by RFCs.
コンピュータ会議の規格を提供することによって、それはだれが使用するかに関する問題を解決するべきです。何というコンピュータ。 彼らのコミュニケーションの選択のために彼らの対応者が互換機の上にアカウントを持っているかどうかを心配する必要はなくて、これがVMSからそのだれかを意味するだろうか、またはVMマシンは1人以上の人を説得できます。 電子メール(メール)は、RFC822と共に言いなりになるので、ほとんどの現代の郵送者と共にインターネットでこの位置に既に達しました。 したがって、USENetがメールすることになっているとき話すことであるリアルタイムで会議のこれを予想するのは無理ではありません。 それらについて含んでいますが、RFCsで4(4)、メール、およびニュースだけを含んでいます。
USENet is a vast resource and immensely useful for many people around the globe. It does, however suffer from a high noise to signal ratio. It would be unwise to expect much difference in performance from conferencing.
USENetは広大なリソースであって非常に地球の周りの多くの人々の役に立ちます。 それは苦しんで、しかしながら、高い雑音に苦しんで、比率に合図してください。 会議からの性能のかなりの違いを予想するのは賢明でないでしょう。
By providing the means for realtime computer conferencing, it opens up a whole new area of usefulness to computers. For both students and staff alike, it opens up new possibilities. In educational institutions where there is a high level of project work with groups of more than 2, it means that students can work from home or other remote places and discuss their project with their fellow students in a manner which would be similar to all students having a conventional meeting or conference. This same situation also applies to staff members. For those who have previously relied on email between fellow researchers in many remote institutions, computer conferencing brings the world together, onto the researchers screen where they can trade ideas and code in real time. Traditionally to achieve these goals, the phone would have been used and a teleconference setup and
リアルタイム用コンピュータ会議を手段に提供することによって、それはコンピュータへの有用性の真新しい領域を開けます。 学生もスタッフについても両方に関しては、それは新しい可能性を開けます。 2人以上のグループとの高いレベルのプロジェクト作業がある学園では、それが、学生がホームか他の遠い所から働いて、学生同士で従来のミーティングか会議を持っているすべての学生と同様の方法でそれらのプロジェクトについて議論できることを意味します。 また、この同じ状況は、メンバーを配置するのに申し込みます。 以前に仲間研究者の間の多くのリモート団体におけるメールを当てにした人に関しては、コンピュータ会議は彼らがリアルタイムで考えとコードを取り引きできるスクリーンを一緒に研究者への世界にもたらします。 そして電話が伝統的に、これらの目標を達成するためには、使用されていて電子会議セットアップであっただろう。
Reed [Page 3] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[3ページ]。
it will probably remain so for many years to come with video phones too. However, with phone conferencing, when people talk over each other, the quality of the discussion is degraded.
それはたぶんテレビ電話でもそれほどこれから何年も残るでしょう。 しかしながら、電話会議で、人々が互いについて論議するとき、議論の品質は降格しています。
2.0 Goals for what a protocol should provide
プロトコルがそうするべきであることの2.0の目標が提供されます。
In producing a protocol for conferencing over computer networks, the following problems must be considered:
会議のためにコンピュータネットワークの上にプロトコルを作成する際に、以下の問題を考えなければなりません:
2.1 State Information problems
2.1 州の情報問題
The number of users who are a part of the conference may fluctuate continuously by a large amount over any given period of time. The protocol should endevour to make disruptions such as these as smooth as possible but at the same time, keep the realtime feel in the conference. It is not acceptable to buffer a user who quits for any given time but at the same time, if a server has network problems with connecting to another one, it may be wise to find some way around the continual stream of state messages that are passed - or - at least a way to reduce the number.
多量に従って、会議の一部であるユーザの数はどんな与えられた期間にわたっても絶え間なく変動するかもしれません。 プロトコルはこれらなどの分裂をできるだけ滑らかにするようにendevourされるべきですが、同時に、会議でリアルタイムで感じを保ってください。 与えられた何時でもやめるユーザをバッファリングするのは許容できませんが、同時に、サーバに別の1つに接続することに関するネットワーク問題があるなら、状態の絶え間ない流れの周りの何らかの道が通過されるメッセージであることがわかるのは賢明であるかもしれません。----数を減らす少なくとも方法。
2.2 Network barriers
2.2 ネットワークバリア
Members of a conference may be on physical networks which cannot directly communicate with each other, such as those used from a host on a commercial network talking via a bridge to someone from a network directly connected to a network directly accessible from theirs. So in this case, the users involved have no need to directly use the bridge (as required by unix talk) since the server on the gateway host provides a way for messages to be passed in and out of the unreachable sections. In this case also, there is a minimum security risk to the network which is otherwise unreachable.
会議のメンバーは直接互いにコミュニケートできない物理ネットワークの一員であるかもしれません、ブリッジを通して話す商業ネットワークのホストからだれかまで直接接続されたネットワークから彼等のものから直接アクセスしやすいネットワークまで使用されるものなどのように。 それで、この場合、かかわったユーザには、ゲートウェイホストの上のサーバが手の届かないセクションについて内外に通過するべきメッセージのための方法を提供するので、直接、ブリッジ(必要に応じて、unixで、話す)を使用する必要が全くありません。 この場合、そうでなければ手が届かないネットワークへの最小のセキュリティリスクがあります。
2.3 User needs
2.3 ユーザの必要性
2.3.1 User privacy
2.3.1 ユーザプライバシー
Members of a conference may wish to exchange ideas privately without fear of others eavesdropping or interrupting the current conference. To facilitate this, there should be some support by the protocol to pass messages from one user/client directly to another.
会議のメンバーは他のものが現在の会議を盗み聞くか、または中断することへの恐怖なしで個人的に考えを出し合いたがっているかもしれません。 これを容易にするために、1人のユーザ/クライアントから直接別のものまでメッセージを通過するプロトコルによる何らかのサポートがあるべきです。
It is also reasonable for a user to want to be able to hide in one way or another from other users, effectively making themself invisible to other users.
また、どうかして他のユーザからユーザがなりたがっている隠れることができるのも妥当です、事実上自分たちを他のユーザにとって目に見えなくして。
Reed [Page 4] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[4ページ]。
2.3.2 Realtime Expectations
2.3.2 リアルタイムで期待
Users will expect conferencing to be real time, giving the thereby demanding that the protocol supply a quick, efficient, reliable and accurate delivery of a message. Only when these requirements are met can a conference system hope to be of any use to its users.
ユーザは、会議がリアルタイムであると予想して、その結果、過酷にそれを与えて、プロトコルはメッセージの迅速で、効率的で、信頼できて正確な配送を供給します。 これらの必要条件が満たされるときだけ、会議電話方式は、ユーザにはどんな使用もあることを望むことができます。
2.4 Message Delivery
2.4 メッセージ配送
2.4.1 Deficiencies in using IP only
2.4.1 IPだけを使用することにおける欠乏
In routing between conference servers, the problem of routing messages is an important issue. If there was a server for the conference at each domain, this wouldn't be an issue, one could simply do some sort of lookup and find the server for it. This is not the case and unless such a server becomes a standard item for unix machines, it is not reasonable to expect it to ever be so. Thus the need for a layer on top of TCP/IP is needed to deliver messages between the servers for the conference.
会議サーバの間のルーティングで、ルーティング・メッセージの問題は切迫した課題です。 会議のためのサーバが各ドメインにあれば、これが問題でなく、人は、単にある種のルックアップをして、それのためにサーバを見つけることができました。 これはそうではありません、そして、そのようなサーバがunixマシンのための標準の項目にならない場合、したがって、かつてそれがそうであると予想するのは妥当ではありません。 したがって、TCP/IPの上の層の必要性が、会議のためのサーバの間にメッセージを提供するのに必要です。
2.4.2 Flexibility
2.4.2 柔軟性
The routing protocol used should not be inflexible and should allow for routes to change over time in much the same way as RIP does now. However, there is no need for a special routing protocol such as RIP since this is already part of IP's functionality. Routing information should be updated automatically when the server receives information via that route whether it creates or destroys a route.
大体同じようなやり方でRIPが現在するように、使用されるルーティング・プロトコルは、融通がきかないはずがなく、ルートが時間がたつにつれて変化するのを許容するべきです。 しかしながら、RIPなどの特別なルーティング・プロトコルの必要は、これが既にIPの機能性の一部であるので、全くありません。 ルートを作成するか、または破壊することにかかわらず自動的に、サーバがいつそのルートで情報を受け取るかというルート設定情報をアップデートするべきです。
2.4.3 Building a flexible transport protocol on top of existing ones
2.4.3 存在の上のフレキシブルなトランスポート・プロトコルにものを築き上げること。
If such a conferencing service is built upon TCP/IP, it is therefore possible to build an abstract routing model which has no relation to the TCP/IP model. However, it is not wise to ignore the presence of either TCP or IP since by integrating them into the protocol, it is easier to use their strengths. If the protocol relies too heavily on TCP/IP features, it will also inherit some of its weaknesses. These maybe taken for granted, but it is worth keeping them in mind when designing a protocol to be both reliable, efficient and useful.
したがって、そのような会議サービスがTCP/IPで組み込まれるなら、TCP/IPモデルに関係がない抽象的なルーティングモデルを造るのは可能です。 しかしながら、それらの強さを使用するのがそれらをプロトコルと統合することによって、より簡単であるので、TCPかIPのどちらかの存在を無視するのは賢明ではありません。 また、プロトコルがあまりに大いにTCP/IP機能を当てにすると、それは弱点のいくつかを引き継ぐでしょう。 多分当然のことと思われたこれら、それだけは信頼できて、効率的であって、かつ役に立つようにプロトコルを設計するとき、それらを覚えておく価値があります。
2.5 Network Structure
2.5 ネットワーク構造
2.5.1 Size
2.5.1 サイズ
The potential userbase of a conferencing system using the internet should not be underestimated. It is therefore desirable that the conferencing system should be as distributed as possible, and as little state information kept as possible. If the IRC network is
インターネットを使用する会議システムの潜在的userbaseを過小評価するべきではありません。 したがって、会議システムができるだけ分配されているべきであり、州の情報が同じくらいほとんど可能な状態で保たれなかったのは、望ましいです。 IRCネットワークがそうなら
Reed [Page 5] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[5ページ]。
taken as a guide, with 800 users on 140 servers in some 200 channels, the server was using over 1MB of memory. Due to the nature of conferencing and the server being run as a daemon, this memory was hardly ever swapped out. For this reason, servers should aim to only be authoritive about required users, channels and servers and keep up to date information on these.
140のサーバの800人のユーザと共にガイドとしておよそ200個のチャンネルで取ります、サーバは1MB以上のメモリを使用していました。 会議の本質とデーモンとして実行されるサーバのため、このメモリは外でほとんど決して交換されませんでした。 この理由で、サーバは、必要なユーザ、チャンネル、およびサーバの周りのauthoritiveだけであり、これらの情報が時代について行かせることを目指すべきです。
There is also no requirement that a global conferencing system be built, although it is an ideal arena to show the strengths of the network. It also goes without saying that it shows up a lot of its weaknesses too.
また、ネットワークの強さを示しているために、それが理想的なアリーナであるのにもかかわらずの、グローバルな会議システムが構築されるという要件は全くありません。 また..言うまでもない..目立つ..弱点..また
Any protocol which is developed should operate equally well and efficiently on both a large scale network and on a small scale network.
どんな開発されたプロトコルも大規模ネットワークと小規模にネットワークの両方を等しくよく、効率的に作動させるべきです。
3.0 Usage
3.0 用法
If past usage is any guide, then a network based conferencing system will be largely used by mostly students. This is not as unreasonable as it may sound since students and student accounts easily form the largest body on the internet. To encourage staff or other adults into this field, it might be prudent to reduce the amount of noise and interfearance a bored student (or staff member!) can generate.
過去の用法があらゆるガイドであるなら、ネットワークのベースの会議システムはほとんど学生によって主に使用されるでしょう。 これは学生と学生アカウントが容易に最も大きいボディーをインターネットに形成するので聞こえるかもしれないほど無理ではありません。 スタッフか他の大人達をこの分野に奨励するために、退屈している学生(または、職員!)が生成することができる雑音とinterfearanceの量を減少させるのは慎重であるかもしれません。
Realtime conferencing via computer networks is, however, a very attractive toy to many students. It puts them in touch with the world at no extra charge to them. They are able to construct their own character and mask or hide their real self. This is a field which has already been researched and is an interesting topic to pursue.
しかしながら、コンピュータネットワークを通したリアルタイムで会議は多くの学生への非常に魅力的なおもちゃです。 それは追加料金なしでそれらへの世界と接触してそれらを置きます。 彼らは、それら自身のキャラクタとマスクを構成するか、または現実自己を隠すことができます。 これは、既に研究された分野であり、進めるおもしろい話題です。
4.0 Setting it up
4.0 それをセットアップすること。
4.1 Installation
4.1 インストール
The installation and setup of most network utilities/servers is not something that is commonly discussed. It is, however, a point worth considering here after observations made on the setup and installation of systems such as IRC. If the setup is too easy and requires little work, it is not unreasonable to expect students to "install" it in their own accounts to provide themselves and friends with this service. There is little that can really be done about this except to force servers to listen and connect only to a certain priveledged port(s). This need, however, requires root intervention or aid and it is doubtful whether a service such as this should require such steps.
ほとんどのネットワークユーティリティ/サーバのインストールとセットアップは一般的に議論する何かではありません。 しかしながら、それはIRCなどのシステムのセットアップとインストールのときにされた観測の後にここで考える価値があるポイントです。 セットアップが簡単過ぎ、ほとんど仕事を必要としないなら、学生がこのサービスを自分たちと友人に提供するためにそれら自身のアカウントにそれを「インストールする」と予想するのは無理ではありません。 少ししかサーバが、ある一定のpriveledgedポートだけに聴いて、接続するのを強制する以外に、本当にこれに関してできるありません。 しかしながら、この必要性は根の介入か援助を必要とします、そして、これなどのサービスがそのようなステップを必要とするべきであるかどうかが、疑わしいです。
Reed [Page 6] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[6ページ]。
This problem is not often encountered with other network services since they either require large amounts of disk space to be done properly (news) or require the co-operation of other servers before they work in a full serving role (DNS and use of name servers is a good example of this). Of the two, the latter is a good solution if it can be implemented fairly and well.
彼らが多量の椎間腔が適切に完了しているのが必要である(ニュース)、または完全な給仕の役割で働く(ネームサーバのDNSと使用はこの好例です)前に他のサーバの協力を必要とするので、この問題は他のネットワーク・サービスでしばしば行きあたられるというわけではありません。 2では、それを公正によく実装することができるなら、後者は良いソリューションです。
4.2 Controlling growth
4.2 成長を制御すること。
Is it possible to reasonably control the growth and connectivity of a large realtime conferencing network? Should it be compared to other facilities such as USENet which is commonly available and very widespread with no real central control over who gets news?
合理的に大きいリアルタイムで会議ネットワークの成長と接続性を制御するのは可能ですか? それは一般的に利用可能でだれがニュースを得るかの上の実際の集中管理なしで非常に広範囲のUSENetなどの他の施設と比較されるべきですか?
5.0 Finding the *right* protocol
5.0 *が正しい*プロトコルであることがわかること。
This section deals with points which are central issues when deciding upon a protocol. There are many points to consider when developing a realtime protocol which is going to provide a service to many users simultaneously.
このセクションはプロトコルについて決めるとき、主要な問題であるポイントに対処します。 同時に多くのユーザに対するサービスを提供するリアルタイムでプロトコルを開発すると考えるために、多くのポイントがあります。
5.1 Name for protocol
5.1 プロトコルのための名前
Although names such as IRC and ICB have been used in the past to describe the implementation provided, this document is aimed at stimulating a protocol which is much more general and useful than these. A better name would reflect this. Depending on what network it is implemented on, the Network Conferencing Protocol (NCP) or the Internet Conferencing Protocol (ICP) are two suitable names.
IRCやICBなどの名前は説明する過去に使用されましたが、実装は提供されて、このドキュメントはこれらよりはるかに一般的で役に立つプロトコルを刺激するのを目的とされます。 より良い名前はこれを反映するでしょう。 それがどんなネットワークで実装されるかによるか、Network Conferencingプロトコル(NCP)またはインターネットConferencingプロトコル(ICP)が2つの適当な名前です。
5.2 Responsibilities of conference servers
5.2 会議サーバの責任
5.2.1 Message passing
5.2.1 メッセージ・パッシング
A conferencing server should pass on all messages not destined for itself or its users to the destination as quickly and efficiently as possible. To this end, the server should not be required to do extensive parsing of the incoming message, but rather, look at the header and decide from there whether to send it on in the typical gateway/relay fashion or parse it and pass it to one or more of its users.
会議サーバはできるだけはやく効率的にそれ自体のために運命づけられたというわけではないすべてのメッセージかそのユーザを目的地に伝えるべきです。 このために、入力メッセージの大規模な構文解析をするためにサーバを必要とするべきではありませんが、むしろ、ヘッダーを見てください、そして、そこからユーザのより多くのひとりに典型的なゲートウェイ/リレーが作成するコネにそれを送るか、それを分析して、またはそれを通過するか決めてください。
5.2.2 Who is on?
5.2.2 だれがオンですか?
Any conference server should be able to supply (on request) a list of attached user(s). The attached user(s) should have the option of being able to say whether they wish to show up in such lists.
どんな会議サーバも付属ユーザのリストを提供できるべきです(要求に応じて)。 付属ユーザには、彼らがそのようなリストに現れたがっているかどうか言うことができるオプションがあるべきです。
Reed [Page 7] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[7ページ]。
5.2.3 Who is who?
5.2.3 だれがいるか、だれですか?
All servers should provide *some* method to identify any known user and supply details to the person making the query based on the search key given.
すべてのサーバがどんな知られているユーザも特定して、詳細を人に供給する検索キーに基づいた質問を与える何らかの*メソッドを*に提供するべきです。
5.2.4 Conference security
5.2.4 コンファレンスセキュリティ
Conference servers should not run in such a manner that they deliberately record the private conversation(s) of users which are relying on the server in some way. It might seem that encrypting the message before transmission to other servers in some way would solve this, but this is better left as an option which is implemented in clients and thus leaves it to the users to decide how secure they want their conference to be.
コンファレンスサーバがそのような方法に立候補するべきでないので、彼らは故意に何らかの方法でサーバを当てにしているユーザの密談を記録します。 それは何らかの方法で他のサーバへのトランスミッションがこれを解決する前にメッセージを暗号化しながら、それに見えるかもしれませんが、これはクライアントで実装されて、その結果自分達の会議が彼らがどれくらい安全でありたがっているか決めるようにユーザに任せるオプションとして残されるほうがよいです。
5.2.5 Error reporting
5.2.5 誤り報告
All errors that the server encounters in its running life should one way or another be reported to the operator(s) which are responsible for this. This may include sending messages if an operator is online or logging it to an error file.
サーバが実行している寿命で遭遇するすべての誤りがいずれにしてもこれに責任があるオペレータに報告されるべきです。 これは、オペレータがオンラインであり、誤りファイルにそれを登録しているならメッセージを送るのを含むかもしれません。
5.2.6 Network Friendliness
5.2.6 ネットワーク友情
It is quite easy for any network based application to "abuse" the network it is running on. Also in a relay situation, it is quite possible that a server will become bogged down trying to keep up with just one connection and reduces the performance on an overall scale to all users relying on it. It is therefore recommended that user connections be subject to some sort of monitoring and flood control to stop them dumping large amounts of spurious data and causing the server to slow down.
どんなネットワークのベースのアプリケーションもそれが動いているネットワークを「乱用」であることは、かなり簡単です。 リレー状況でも、サーバがちょうど1つの接続について行こうとするところで泥沼に落ち込まれるようになって、総合的なスケールでそれを当てにするすべてのユーザに性能を抑えるのは、かなり可能です。 したがって、ユーザ接続を条件としているそれは彼らが多量の偽りのデータをどさっと落として、サーバを遅くならせるのを止めるある種のモニターと治水がダウンするのが推薦されます。
The server should also aim to maximise the packet size of all packets written out to the network. Not only does this make the packet/bytes statistics look nice, but also increases the efficiency of the server by reducing the time it spends in the system state waiting/doing IO operations such as read/write. The cost here is a fractional decrease in the real-time efficiency of the server.
また、サーバは、ネットワークに書き上げられたすべてのパケットのパケットサイズを最大にすることを目指すべきです。 パケット/バイト統計がこれで格好よく見えるだけではなく、それがシステムで過ごす時間を短縮するのによるサーバの効率の増加は読むか、または書くような待ち/するIO作業を述べもします。 ここの費用はサーバのリアルタイムの効率の断片的な減少です。
5.2.7 To ASCII or not to ASCII
5.2.7、ASCIIかASCIIでない
Given that most of the widely used Internet protocols such as SMTP, NNTP and FTP are all based on commands which are given via ASCII strings, there seems no reason why a conferencing protocol should be any different. The gains from going to binary are marginal and debugging/testing is not as easy as with ASCII. However, it is not
SMTPや、NNTPやFTPなどの広く使用されたインターネットプロトコルの大部分がASCIIストリングで与えられているコマンドにすべて基づいているなら、いずれか異なるなら会議プロトコルがそうする理由は全く見えません。 行くのからのバイナリーへの利得がマージンであり、デバッグ/テストはASCIIほど簡単ではありません。 しかしながら、それはそうではありません。
Reed [Page 8] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[8ページ]。
unreasonable for some part of the protocol to be done in binary.
バイナリーでプロトコルの何らかの部分をするのにおいて、無理です。
5.2.8 Queries or messages to a server and replies
5.2.8 サーバと回答への質問かメッセージ
For implementation of server queries, it is quite acceptable to use ASCII messages which are made up of words. (Any string of characters which doesn't start with a number). Replies should be some sort of numeric. This is a follow on from from 5.2.7 where all of FTP, NNTP and SMTP work in this manner. By reserving numerics *just* for server replies, there can be no confusion about whether the message is going to or from a server.
サーバ質問の実装において、単語で作られるASCIIメッセージを使用するのはかなり許容できます。 (数から始まらないキャラクタのどんなストリングも。) 回答はある種の数値であるべきです。 これ、尾行が進行中、5.2 .7 FTP、NNTP、およびSMTPのすべてがこの様に働いているところ。 数値*を予約することによって、サーバのためのまさしく*は返答して、混乱が全くメッセージがサーバかサーバから行くかどうかあるはずがありません。
5.3 Responsibilities of clients
5.3 クライアントの責任
This section discusses the obligations of clients which are connected to a conference server.
このセクションは会議サーバに接続されるクライアントの義務について論じます。
5.3.1 Providing accurate information
5.3.1 的確な情報を提供すること。
Expecting accurate information is foolish, it matters not for most of the internet, but those that we do wish to trace wont give such information. A client is expected to provide accurate and valid information to the server it connects to so that confusion about who is who is not a problem. Optionally, the server may decide to not trust the information from the client and use some authentication scheme that is open to it for such.
的確な情報を予想するのが愚かである、インターネットのどんな大部分のためにも重要ではありませんが、習慣をたどりたいと思うものはそのような情報を教えます。 クライアントがだれが問題でないということであるかに関してその混乱をそうに接続するというサーバへの正確で有効な情報を提供すると予想されます。 任意に、サーバは、クライアントから情報を信じて、そのようなものに何らかのそれに開かれている認証体系を使用しないと決めるかもしれません。
5.3.2 Client as servers
5.3.2 サーバとしてのクライアント
If a client is acting as a server and accepting direct connections from other clients, the client should provide information about users as discussed in 5.2.3. It is not necessary that a client be able to handle complex methods of communication such as channels and their advanced forms, but they should at least provide users with being able to send messages to other users.
クライアントがサーバとして務めて、他のクライアントからダイレクト接続を認めているなら、クライアントが中で議論するようにユーザの情報を提供するべきである、5.2、.3 クライアントがコミュニケーションのチャンネルや彼らの進行型などの複雑なメソッドを扱うことができるのは必要ではありませんが、それらは他のユーザにメッセージを送ることができるのをユーザに少なくとも提供するべきです。
An example of this type of program might be Xtv where one or more users can connect to another Xtv client program using Xtv clients.
このタイプに関するプログラムに関する例は1人以上のユーザがXtvクライアントを使用することで別のXtvクライアントプログラムに接続できるXtvであるかもしれません。
In the case of X windows and perhaps in other areas, one it to ask the destination user to run a program in a similar manner to unix talk.
ケース、X-windowsと恐らくコネ他の領域、1つでは、プログラムを同じようにunixに動かすように目的地ユーザに頼むそれは話します。
Reed [Page 9] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[9ページ]。
5.4 How complex should the protocol be?
5.4 プロトコルはどれくらい複雑であるべきですか?
5.4.1 User identification
5.4.1 ユーザ登録名
When a user signs onto a system that has an implementation of a conferencing protocol, they are usually asked or given some sort of unique key by which they are later able to be referenced by. In a large system, it may be such that any key which has meaning to the user(s) will not be sufficient and that collisions will occur with such. It is therefore suggested that a server generate an identifier for each new user it has. This identifier must not only be unique in space, but also time. It is not reasonable for the user to ever have to be aware of what this identifier is, it should only be known by servers which *need* to know. A similar system to that used by NNTP/SMTP is a fair implementation of such a scheme.
ユーザが会議プロトコルの実装を持っているシステムに署名するとき、通常、それらが参照をつけることができる状態で、より遅れているある種のユニークキーをそれらに尋ねるか、または与えます。 大規模システムでは、ユーザに意味を持っているどんなキーも十分でなく、衝突がそのようなもので起こるのは、そのようなものであるかもしれません。 したがって、サーバがそれがいるそれぞれの新しいユーザのために識別子を生成することが提案されます。 この識別子はしかし、スペース、時間だけでもユニークであるはずがありません。 ユーザがこの識別子が何であるかを意識していなければならないのが、妥当でない、どの*が知るために*を必要とするかがサーバによって知られているだけであるべきです。 NNTP/SMTPによって使用されたそれへの同様のシステムはそのような体系の公正な実装です。
5.4.2 Trees and cycles
5.4.2木とサイクル
Due to the structure of the network being cyclic or forming loops, it is quite natural to want to emulate this within the protocol that is available for users. This has several advantages over trees, mainly the average path between any 2 nodes being shorter. A cyclic structure also poses many problems in getting messages delivered and keeping the connected users and servers up to date. The main problem with using the tree model is that a break in one part of the tree needs to be communicated to all other parts of the tree to keep some sort of realism about it. The problem here is that such communications happen quite often and a lot of bandwidth is needlessly generated. By implementing a protocol which supports a cyclic graph of its connectivity, breakages are less damaging except when it is a leaf or branch that breaks off.
ネットワークの構造のため、周期的であるか、形成が輪にされて、ユーザに利用可能なプロトコルの中でこれを見習いたいのはかなり当然です。 これには、主にどんな2つのノードの間の平均した経路が、より短くて、木よりいくつかの利点があります。 また、循環的構造はメッセージを提供させて、接続ユーザとサーバが時代について行かせる際に多くの問題を引き起こします。 木のモデルを使用することに関する主な問題は木の一部での中断が、それに関するある種のリアリズムを保つために木の他のすべての部分とコミュニケートする必要があるということです。 そのようなコミュニケーションがかなりしばしば起こるという問題がここにあります、そして、多くの帯域幅が不必要に生成されます。 接続性の周期的なグラフをサポートするプロトコルを実装することによって、それが分解する葉かブランチである時以外に、折損はそれほどダメージが大きくはありません。
5.5 Protocol summary
5.5 プロトコル概要
It is not expected that any protocol that meets the above demands will be either easy to arrive at or easy to implement. Some of the above requirements may seem to be exotic, unnecessary or not worth the effort. After viewing previous conferencing programs and how they work, many short comings can be seen in taking shortcuts.
上の需要にこたえるどんなプロトコルも道具で到着しやすいか、または道具に簡単にならないと予想されます。 上記の要件のいくつかが取り組みのエキゾチックであるか、不要であるかまたは価値がないように思えるかもしれません。 前の会議プログラムとそれらがどう働いているかを見た後に、近道を取る際に多くの短いcomingsを見ることができます。
6.0 Security Considerations
6.0 セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Reed [Page 10] RFC 1324 Computer Network Conferencing May 1992
コンピュータネットワーク会議1992年5月にRFC1324をアシで飾ってください[10ページ]。
7.0 Author's Address
7.0 作者のアドレス
Darren Reed 4 Pateman Street Watsonia, Victoria 3087 Australia
ダーレンReed4ペイトマン通りWatsonia、ビクトリア・3087オーストラリア
Email: avalon@coombs.anu.edu.au
メール: avalon@coombs.anu.edu.au
Reed [Page 11]
リード[11ページ]
一覧
スポンサーリンク