RFC3678 日本語訳
3678 Socket Interface Extensions for Multicast Source Filters. D.Thaler, B. Fenner, B. Quinn. January 2004. (Format: TXT=36320 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Thaler
Request for Comments: 3678 Microsoft
Category: Informational B. Fenner
AT&T Research
B. Quinn
Stardust.com
January 2004
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3678年のマイクロソフトカテゴリ: 情報のB.のAT&T研究B.クインStardust.comフェナー2004年1月
Socket Interface Extensions for Multicast Source Filters
マルチキャストソースフィルタのためのソケットインタフェース拡大
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications.
IPv4のためのインターネットGroup Managementプロトコル(IGMPv3)とIPv6のためのMulticast Listenerディスカバリー(MLDv2)はアプリケーションがマルチキャストグループ会員資格でソースフィルタを急送する能力を加えます。(受信側アプリケーションはそれでマルチキャストトラフィックを受け入れる送付者(ソース)のセットを決定できます)。 また、この能力は多くへの1つのタイプマルチキャストアプリケーションのサポートを簡素化します。
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.
このドキュメントは、IP Multicastグループ会員資格のためにソースフィルタを管理するために新しいソケットオプションと機能を指定します。 また、それは、これらの新しい適用業務プログラム・インタフェース(API)に入出力議論を提供するためにソケット構造を定義します。 これらの拡大は、特徴をフィルターにかけるソースへのアクセスを提供するように最小変化をシステムに取り入れて、既存のマルチキャストアプリケーションに完全な両立性を提供している間、設計されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Considerations. . . . . . . . . . . . . . . . . . . . . 3
2.1 What Needs to be Added . . . . . . . . . . . . . . . . . . 4
2.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Headers. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Structures . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of APIs. . . . . . . . . . . . . . . . . . . . . . . . 5
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 問題を設計してください。 . . . . . . . . . . . . . . . . . . . . 3 2.1 Addedの.42.2Data Types. . . . . . . . . . . . . . . . . . . . . . . . 4 2.3のHeadersである必要があること。 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4の構造. . . . . . . . . . . . . . . . . . . . . . . . 4 3。 APIの概要。 . . . . . . . . . . . . . . . . . . . . . . . 5
Thaler, et al. Informational [Page 1] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [1ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
4. IPv4 Multicast Source Filter APIs . . . . . . . . . . . . . . . 6
4.1 Basic (Delta-based) API for IPv4. . . . . . . . . . . . . . 6
4.1.1 IPv4 Any-Source Multicast API. . . . . . . . . . . . 7
4.1.2 IPv4 Source-Specific Multicast API . . . . . . . . . 7
4.1.3 Error Codes. . . . . . . . . . . . . . . . . . . . . 8
4.2 Advanced (Full-state) API for IPv4. . . . . . . . . . . . . 8
4.2.1 Set Source Filter. . . . . . . . . . . . . . . . . . 8
4.2.2 Get Source Filter. . . . . . . . . . . . . . . . . . 9
5: Protocol-Independent Multicast Source Filter APIs . . . . . . . 10
5.1 Basic (Delta-based) API . . . . . . . . . . . . . . . . . . 10
5.1.1 Any-Source Multicast API . . . . . . . . . . . . . . 11
5.1.2 Source-Specific Multicast API. . . . . . . . . . . . 11
5.2 Advanced (Full-state) API . . . . . . . . . . . . . . . . . 11
5.2.1 Set Source Filter. . . . . . . . . . . . . . . . . . 11
5.2.2 Get Source Filter. . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 13
8. Appendix A: Use of ioctl() for full-state operations . . . . . 14
8.1. IPv4 Options. . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Protocol-Independent Options. . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
4. IPv4マルチキャストソースフィルタAPI. . . . . . . . . . . . . . . 6 4.1のIPv4に、基本的な(デルタベースの)API。 . . . . . . . . . . . . . 6 4.1 .1IPv4、いくらか、-、ソース、マルチキャストAPI。 . . . . . . . . . . . 7 4.1 .2 IPv4のソース特有のマルチキャストAPI. . . . . . . . . 7 4.1.3のエラーコード。 . . . . . . . . . . . . . . . . . . . . 8 4.2のIPv4に、高度な(完全な状態)API。 . . . . . . . . . . . . 8 4.2 .1はソースフィルタを設定します。 . . . . . . . . . . . . . . . . . 8 4.2 .2はソースにフィルタを届けます。 . . . . . . . . . . . . . . . . . 9 5: プロトコルから独立しているマルチキャストソースフィルタAPI. . . . . . . 10 5.1の基本的な(デルタベースの)API. . . . . . . . . . . . . . . . . . 10 5.1.1、いくらか、-、ソース、マルチキャストAPI. . . . . . . . . . . . . . 11 5.1.2のソース特有のマルチキャストAPI。 . . . . . . . . . . . 11 5.2はAPI. . . . . . . . . . . . . . . . . 11 5.2.1セットソースフィルタを進めました(完全な状態)。 . . . . . . . . . . . . . . . . . 11 5.2 .2はソースにフィルタを届けます。 . . . . . . . . . . . . . . . . . 12 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 13 7. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 13 8. 付録A: ioctl()の完全な州の操作. . . . . 14 8.1の使用。 IPv4オプション。 . . . . . . . . . . . . . . . . . . . . . . 14 8.2. プロトコルから独立しているオプション。 . . . . . . . . . . . . . . 15 9. 引用規格. . . . . . . . . . . . . . . . . . . . . 16 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 16 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 18
1. Introduction
1. 序論
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with applications that employ multicast source filters. Changes are required to the sockets API to support such filtering and this memo describes these changes.
TCP/IPアプリケーションのためのデファクトスタンダード適用業務プログラム・インタフェース(API)は「ソケット」インタフェースです。 このAPIは1980年代前半のUnixのために開発されましたが、また、それはさまざまな非unixシステムの上で実装されました。ソケットAPIを使用することで書かれたTCP/IPアプリケーションは過去に高度合いの移植性を楽しみました、そして、私たちはマルチキャストソースフィルタを使うアプリケーションがある同じ移植性が欲しいと思います。 変化はソケットAPIにそのようなフィルタリングをサポートしなければなりません、そして、このメモはこれらの変化について説明します。
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new APIs. These extensions are designed to provide access to the source filtering features required by applications, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.
このドキュメントは、IP Multicastグループ会員資格のためにソースフィルタを管理するために新しいソケットオプションと機能を指定します。 また、それは、これらの新しいAPIに入出力議論を提供するためにソケット構造を定義します。 これらの拡大は、最小変化をシステムに取り入れて、既存のマルチキャストアプリケーションに完全な両立性を提供する間アプリケーションで必要である特徴をフィルターにかけるソースへのアクセスを提供するように設計されています。
Furthermore, RFC 3493 [1] defines socket interface extensions for IPv6, including protocol-independent functions for most operations.
その上、RFC3493[1]はほとんどの操作のためのプロトコルから独立している機能を含むIPv6のためにソケットインタフェース拡大を定義します。
Thaler, et al. Informational [Page 2] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [2ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
However, while it defines join and leave functions for IPv6, it does not provide protocol-independent versions of these operations. Such functions will be described in this document.
しかしながら、それをゆったり過ごしてください、定義、機能をIPv6に接合して、残してください、そして、それはこれらの操作のプロトコルから独立しているバージョンを供給しません。 そのような機能は本書では説明されるでしょう。
The reader should note that this document is for informational purposes only, and that the official standard specification of the sockets API is [2].
読者はこのドキュメントが情報の目的だけのためのものであり、ソケットAPIの公式の標準の仕様が[2]であることに注意するべきです。
2. Design Considerations
2. デザイン問題
There are a number of important considerations in designing changes to this well-worn API:
この陳腐なAPIへの変化を設計するのにおいて多くの重要な問題があります:
o The API changes should provide both source and binary
compatibility for programs written to the original API. That
is, existing program binaries should continue to operate when
run on a system supporting the new API. In addition, existing
applications that are re-compiled and run on a system
supporting the new API should continue to operate. Simply put,
the API changes for multicast receivers that specify source
filters should not break existing programs.
o API変化はオリジナルのAPIに書かれたプログラムにソースとバイナリ互換性の両方を供給するはずです。 新しいAPIをサポートするシステムに実行されると、すなわち、既存のプログラム2種混合毒ガスは、作動し続けるべきです。 新しいAPIをサポートする再コンパイルされて、システムで動く既存のアプリケーションは、さらに、作動し続けるべきです。 簡単に言えば、ソースフィルタを指定するマルチキャスト受信機のためのAPI変化は既存のプログラムを壊すはずがありません。
o The changes to the API should be as small as possible in order
to simplify the task of converting existing multicast receiver
applications to use source filters.
o APIへの変化は、タスクを単純化するためにできるだけソースフィルタを使用するために既存のマルチキャスト受信側アプリケーションを変換するのにおいて小さいはずです。
o Applications should be able to detect when the new source
filter APIs are unavailable (e.g., calls fail with the ENOTSUPP
error) and react gracefully (e.g., revert to old non-source-
filter API or display a meaningful error message to the user).
o アプリケーションが新しいソースフィルタAPIがいつ入手できないかを(ENOTSUPP誤りに応じて、例えば呼び出しは失敗します)検出して、優雅に反応できるべきである、(例えば、古く戻ってください、非、-、ユーザへのフィルタAPIかディスプレイの出典を明示しているa重要なエラーメッセージ)
o Lack of type-safety in an API is a bad thing which should be
avoided when possible.
o APIのタイプ安全の不足は可能であるときに避けられるべきである悪いものです。
Several implementations exist that use ioctl() for a portion of the functionality described herein, and for historical purposes, the ioctl API is documented in Appendix A. The preferred API, however, includes new functions. The reasons for adding new functions are:
ここに説明された機能性の部分にioctl()を使用するいくつかの実装が存在しています、そして、歴史的な目的のために、ioctl APIはAppendix A.に記録されます。しかしながら、都合のよいAPIは新しい機能を含んでいます。 新しい機能を加える理由は以下の通りです。
o New functions provide type-safety, unlike ioctl, getsockopt,
and setsockopt.
o 新しい機能はioctl、getsockopt、およびsetsockoptと異なってタイプ安全を提供します。
o A new function can be written as a wrapper over an ioctl,
getsockopt, or setsockopt call, if necessary. Hence, it
provides more freedom as to how the functionality is
implemented in an operating system. For example, a new
function might be implemented as an inline function in an
o 必要なら、ラッパーとしてioctl、getsockopt、またはsetsockopt呼び出しの上に新しい機能を書くことができます。 したがって、機能性がオペレーティングシステムでどう実装されるかに関してそれは、より多くの自由を提供します。 例えば、新しい機能はインライン関数として中で実装されるかもしれません。
Thaler, et al. Informational [Page 3] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [3ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
include file, or a function exported from a user-mode library
which internally uses some mechanism to exchange information
with the kernel, or be implemented directly in the kernel.
ファイル、またはカーネルで情報交換するのに内部的に何らかのメカニズムを使用するユーザ・モードライブラリからエクスポートされた機能を含めるか、または直接カーネルで実装されてください。
o At least one operation defined herein needs to be able to both
pass information to the TCP/IP stack, as well as retrieve
information from it. In some implementations this is
problematic without either changing getsockopt or using ioctl.
Using new functions avoids the need to change such
implementations.
o ここに定義された少なくとも1つの操作が、TCP/IPスタックに情報を移って、それから情報を検索できる必要があります。 いくつかの実装では、getsockoptを変えるか、またはioctlを使用しないで、これは問題が多いです。 新しい機能を使用すると、そのような実装を変える必要性は避けられます。
2.1. What Needs to be Added
2.1. 何が、Addedである必要がありますか。
The current IP Multicast APIs allow a receiver application to specify the group address (destination) and (optionally) the local interface. These existing APIs need not change (and cannot, to retain binary compatibility). Hence, what is needed are new source filter APIs that provide the same functionality and also allow receiver multicast applications to:
現在のIP Multicast APIで、受信側アプリケーションはグループアドレス(目的地)と(任意に)局所界面を指定できます。 そして、既存のAPIが必要とするこれらが変化しない、(バイナリ互換性を保有する、)であることができる したがって、必要であるものは同じ機能性を前提として、また以下のことを受信機マルチキャストアプリケーションは許容する新しいソースフィルタAPIです。
o Specify zero or more unicast (source) address(es) in a source
filter.
o ソースフィルタでゼロか、より多くのユニキャスト(ソース)アドレス(es)を指定してください。
o Determine whether the source filter describes an inclusive or
exclusive list of sources.
o ソースフィルタがソースの包括的であるか排他的なリストについて説明するかどうか決定してください。
The new API design must enable this functionality for both IPv4 and IPv6.
新しいAPIデザインはIPv4とIPv6の両方のためのこの機能性を可能にしなければなりません。
2.2. Data Types
2.2. データ型
The data types of the structure elements given in this memo are intended to be examples, not absolute requirements. Whenever possible, data types from POSIX 1003.1g [2] are used: uintN_t means an unsigned integer of exactly N bits (e.g., uint32_t).
このメモで与えられた構造要素に関するデータ型は絶対条件ではなく、例であることを意図します。 可能であるときはいつも、POSIX1003.1g[2]からのデータ型は使用されています: uintN_tはちょうどNビット(例えば、uint32_t)の符号のない整数を意味します。
2.3. Headers
2.3. ヘッダー
When function prototypes and structures are shown, we show the headers that must be #included to cause that item to be defined.
関数原型と構造が見せられると、私たちは#、を含んでいて、その項目が定義されることを引き起こすためにそうしなければならないヘッダーを見せています。
2.4. Structures
2.4. 構造
When structures are described, the members shown are the ones that must appear in an implementation. Additional, nonstandard members may also be defined by an implementation. As an additional
構造が説明されるとき、見せられたメンバーは実装に現れなければならないものです。 また、追加していて、標準的でないメンバーは実装によって定義されるかもしれません。 追加
Thaler, et al. Informational [Page 4] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [4ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
precaution, nonstandard members could be verified by Feature Test Macros as described in [2]. (Such Feature Test Macros are not defined by this RFC.)
注意、標準的でないメンバーは[2]で説明されるようにFeature Test Macrosによって確かめられるかもしれません。 (そのようなFeature Test MacrosはこのRFCによって定義されません。)
The ordering shown for the members of a structure is the recommended ordering, given alignment considerations of multibyte members, but an implementation may order the members differently.
「マルチ-バイト」メンバーの整列問題を考えて、構造の部材のために示された注文はお勧めの注文ですが、実装はメンバーを異なって命令するかもしれません。
3. Overview of APIs
3. APIの概要
There are a number of different APIs described in this document that are appropriate for a number of different application types and IP versions. Before providing detailed descriptions, this section provides a "taxonomy" with a brief description of each.
本書では説明された多くの多くの異なったアプリケーションタイプとIPバージョンに、適切な異なったAPIがあります。 詳述を提供する前に、このセクションは「分類学」にそれぞれの簡単な説明を提供します。
There are two categories of source-filter APIs, both of which are designed to allow multicast receiver applications to designate the unicast address(es) of sender(s) along with the multicast group (destination address) to receive.
ソースフィルタAPIの2つのカテゴリがあります。その両方が、マルチキャスト受信側アプリケーションが受信するためにマルチキャストグループ(送付先アドレス)に伴う送付者の(es)にユニキャストアドレスを指定するのを許容するように設計されています。
o Basic (Delta-based): Some applications desire the simplicity of
a delta-based API in which each function call specifies a
single source address which should be added to or removed from
the existing filter for a given multicast group address on
which to listen. Such applications typically fall into either
of two categories:
o 基本的(デルタベースの): いくつかのアプリケーションが各ファンクションコールが既存のフィルタから聴く与えられたマルチキャストグループアドレスに加えられるべきであるただ一つのソースアドレスを指定したか、または取り外したデルタベースのAPIの簡単さを望んでいます。 そのようなアプリケーションは2つのカテゴリのどちらかに通常なります:
+ Any-Source Multicast: By default, all sources are accepted.
Individual sources may be turned off and back on as needed
over time. This is also known as "exclude" mode, since the
source filter contains a list of excluded sources.
+、いくらか、-、ソース、マルチキャスト: デフォルトで、すべてのソースを受け入れます。 個々のソースでは、時間がたつにつれて必要であるようにオフにされて、戻るかもしれません。 またモードを「除く」とき知られていてこれはソースフィルタが除かれたソースのリストを含んでいるからです。
+ Source-Specific Multicast: Only sources in a given list are
allowed. The list may change over time. This is also known
as "include" mode, since the source filter contains a list
of included sources.
+ ソース特有のマルチキャスト: 与えられたリストのソースだけが許容されています。 リストは時間がたつにつれて、変化するかもしれません。 またモードを「含んでいる」とき知られていてこれはソースフィルタが含まれているソースのリストを含んでいるからです。
This API would be used, for example, by "single-source"
applications such as audio/video broadcasting. It would
also be used for logical multi-source sessions where each
source independently allocates its own Source-Specific
Multicast group address.
例えば、このAPIはオーディオ/ビデオ放送などの「単独のソース」応用で使用されるでしょう。 また、それは各ソースが独自にそれ自身のSource特有のMulticastグループアドレスを割り当てる論理的なマルチソースセッションに使用されるでしょう。
o Advanced (Full-state): This API allows an application to define
a complete source-filter comprised of zero or more source
addresses, and replace the previous filter with a new one.
o 高度(完全な状態): このAPIで、アプリケーションは、ゼロか以上から成る完全なソースフィルタソースアドレスを定義して、前のフィルタを新しいものに取り替えます。
Thaler, et al. Informational [Page 5] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [5ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
Applications which require the ability to switch between filter
modes without leaving a group must use a full-state API (i.e.,
to change the semantics of the source filter from inclusive to
exclusive, or vice versa).
グループを出ないでフィルタモードを切り換える能力を必要とするアプリケーションは完全な州のAPI(すなわち、逆もまた同様にソースフィルタの意味論を包括的であるのから排他的に変える)を使用しなければなりません。
Applications which use a large source list for a given group
address should also use the full-state API, since filter
changes can be done atomically in a single operation.
また、与えられたグループアドレスに大きいソース・リストを使用するアプリケーションは完全な州のAPIを使用するべきです、ただ一つの操作で原子論的にフィルタ交換ができるので。
The above types of APIs exist in IPv4-specific variants as well as with protocol-independent variants. One might ask why the protocol- independent APIs cannot accommodate IPv4 applications as well as IPv6. Since any IPv4 application requires modification to use multicast source filters anyway, it might seem like a good opportunity to create IPv6-compatible source code.
上のタイプのAPIはIPv4特有の異形とプロトコルから独立している異形で存在しています。 人は、プロトコルの独立しているAPIがなぜIPv6と同様にIPv4アプリケーションを収容できないかを尋ねるかもしれません。 どんなIPv4アプリケーションもとにかくマルチキャストソースフィルタを使用するために変更を必要とするので、IPv6コンパチブルソースコードを作成する好機のように見えるかもしれません。
The primary reasons for extending an IPv4-specific API are:
IPv4特有のAPIを広げるプライマリ理由は以下の通りです。
o To minimize changes needed in existing IPv4 multicast
application source code to add source filter support.
o 変化を最小にするのは、既存のIPv4マルチキャストアプリケーションソースコードにおいてソースフィルタサポートを加える必要がありました。
o To avoid overloading APIs to accommodate the differences
between IPv4 interface addresses (e.g., in the ip_mreq
structure) and interface indices.
o IPv4インターフェース・アドレス(例えば、ip_mreq構造の)とインタフェースインデックスリストの違いを収容するためにAPIを積みすぎるのを避けるために。
4. IPv4 Multicast Source Filter APIs
4. IPv4マルチキャストソースフィルタAPI
Version 3 of the Internet Group Management Protocol (IGMPv3) [3] and version 2 of the Multicast Listener Discovery (MLDv2) protocol [4] provide the ability to communicate source filter information to the router and hence avoid pulling down data from unwanted sources onto the local link. However, source filters may be implemented by the operating system regardless of whether the routers support IGMPv3 or MLDv2, so when the source-filter API is available, applications can always benefit from using it.
インターネットGroup Managementプロトコル(IGMPv3)[3]のバージョン3とMulticast Listenerディスカバリー(MLDv2)プロトコル[4]のバージョン2はソースフィルタ情報をルータに伝えて、したがってデータを引き下げるのを避ける能力を求められていないソースから地方のリンクに供給します。 しかしながら、ルータがIGMPv3かMLDv2をサポートするかどうかにかかわらずソースフィルタがオペレーティングシステムで実装されるかもしれないので、ソースフィルタAPIが利用可能であるときに、アプリケーションはそれを使用するのからいつも利益を得ることができます。
4.1. Basic (Delta-based) API for IPv4
4.1. IPv4に、基本的な(デルタベースの)API
The reception of multicast packets is controlled by the setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these options are used with getsockopt().
マルチキャストパケットのレセプションは以下へまとめられたsetsockopt()オプションで制御されます。 これらのオプションがgetsockopt()と共に使用されるなら、EOPNOTSUPPの誤りは返されます。
Thaler, et al. Informational [Page 6] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [6ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
The following structures are used by both the Any-Source Multicast and the Source-Specific Multicast API:
以下の構造はAny-ソースMulticastとSource特有のMulticast APIの両方によって使用されます:
#include <netinet/in.h>
#<netinet/in.h>を含めてください。
struct ip_mreq {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_interface; /* IP address of interface */
};
*/が_addr imr_multiaddrのstruct; _addr imr_インタフェースのグループ*/structの/*IPアドレス; /*IPがインタフェースを扱うstruct ip_mreq。
struct ip_mreq_source {
struct in_addr imr_multiaddr; /* IP address of group */
struct in_addr imr_sourceaddr; /* IP address of source */
struct in_addr imr_interface; /* IP address of interface */
};
struct ip_mreq_ソースは_addr imr_multiaddr; _addr imr_sourceaddrのグループ*/structの/*IPアドレス; _addr imr_インタフェース;/のソース*/structの/*IPアドレスでインタフェース*/の*IPアドレスをstructします。
4.1.1. IPv4 Any-Source Multicast API
4.1.1. IPv4、いくらか、-、ソース、マルチキャストAPI
The following socket options are defined in <netinet/in.h> for applications in the Any-Source Multicast category:
以下のソケットオプションはAny-ソースMulticastカテゴリにおけるアプリケーションのために<netinet/in.h>で定義されます:
Socket option Argument type IP_ADD_MEMBERSHIP struct ip_mreq IP_BLOCK_SOURCE struct ip_mreq_source IP_UNBLOCK_SOURCE struct ip_mreq_source IP_DROP_MEMBERSHIP struct ip_mreq
ソケットオプションArgumentはIP_ADD_MEMBERSHIP struct ip_mreq IP_BLOCK_SOURCE struct ip_mreq_ソースIP_UNBLOCK_SOURCE struct ip_mreq_ソースIP_DROP_MEMBERSHIP struct ip_mreqをタイプします。
IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP are already implemented on most operating systems, and are used to join and leave an any-source group.
ADD_MEMBERSHIPとIP_DROP_MEMBERSHIPがほとんどのオペレーティングシステムで既に実装されて、使用されているIP_が接合して、いなくなる、いくらか、-、ソース、分類してください。
IP_BLOCK_SOURCE can be used to block data from a given source to a given group (e.g., if the user "mutes" that source), and IP_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then "unmutes" the source).
当然のことのソースから当然のことのグループまでデータを妨げるのにIP_BLOCK_SOURCEを使用できます、そして、(例えば、ユーザがそのソースに「音を消す」なら)これを元に戻すのにIP_UNBLOCK_SOURCEを使用できます(例えば、次に、ユーザがソースを"「非-無言」"であるなら)。
4.1.2. IPv4 Source-Specific Multicast API
4.1.2. IPv4のソース特有のマルチキャストAPI
The following socket options are available for applications in the Source-Specific category:
以下のソケットオプションはSource特有のカテゴリにおけるアプリケーションに利用可能です:
Socket option Argument type IP_ADD_SOURCE_MEMBERSHIP struct ip_mreq_source IP_DROP_SOURCE_MEMBERSHIP struct ip_mreq_source IP_DROP_MEMBERSHIP struct ip_mreq
ソケットオプションArgumentはIP_ADD_SOURCE_MEMBERSHIP struct ip_mreq_ソースIP_DROP_SOURCE_MEMBERSHIP struct ip_mreq_ソースIP_DROP_MEMBERSHIP struct ip_mreqをタイプします。
IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP are used to join and leave a source-specific group.
ADD_SOURCE_MEMBERSHIPとIP_DROP_SOURCE_MEMBERSHIPが使用されているIP_はソース特有のグループに加わって、出ます。
Thaler, et al. Informational [Page 7] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [7ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
IP_DROP_MEMBERSHIP is supported, as a convenience, to drop all sources which have been joined for a particular group and interface. The operations are the same as if the socket had been closed.
IP_DROP_MEMBERSHIPは、特定のグループとインタフェースが一緒に楽しまれたすべてのソースを下げるために便利としてサポートされます。 まるでソケットが閉じられたかのように操作は同じです。
4.1.3. Error Codes
4.1.3. エラーコード
When the option would be legal on the group, but an address is invalid (e.g., when trying to block a source that is already blocked by the socket, or when trying to drop an unjoined group) the error generated is EADDRNOTAVAIL.
オプションがグループで法的でしょうが、アドレスが誤りが生成した病人(例えば、非接合グループを下げようとしながらソケット、またはいつまでに妨げられたか状態で既にそうであるソースを妨げようとするとき)がEADDRNOTAVAILであるということであるときに。
When the option itself is not legal on the group (i.e., when trying a Source-Specific option on a group after doing IP_ADD_MEMBERSHIP, or when trying an Any-Source option without doing IP_ADD_MEMBERSHIP) the error generated is EINVAL.
オプション自体がいつ誤りが作ったグループ(すなわち、_IP ADD_MEMBERSHIPをした後か_IP ADD_MEMBERSHIPをしないでAny-ソースオプションを試みること時グループでSource特有のオプションを試みるのに)で法的でないかは、EINVALです。
When any of these options are used with getsockopt(), the error generated is EOPNOTSUPP.
これらのオプションのどれかがgetsockopt()と共に使用されるとき、生成された誤りはEOPNOTSUPPです。
Finally, if the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when an operation would exceed the maximum.
操作が最大を超えているだろうというとき、最終的に、実装がソースフィルタのソースの最大数で指し値するなら、ENOBUFSは発生しています。
4.2. Advanced (Full-state) API for IPv4
4.2. IPv4に、高度な(完全な状態)API
Several implementations exist that use ioctl() for this API, and for historical purposes, the ioctl() API is documented in Appendix A. The preferred API uses the new functions described below.
このAPIにioctl()を使用するいくつかの実装が存在しています、そして、歴史的な目的のために、ioctl()APIはAppendix A.に記録されます。都合のよいAPIは以下で説明された新しい機能を使用します。
4.2.1. Set Source Filter
4.2.1. セットソースフィルタ
#include <netinet/in.h>
#<netinet/in.h>を含めてください。
int setipv4sourcefilter(int s, struct in_addr interface,
struct in_addr group, uint32_t fmode,
uint32_t numsrc, struct in_addr *slist);
int setipv4sourcefilter(int s、_addrインタフェースのstruct、_addrグループにおけるstruct、uint32_t fmode、uint32_t numsrc、_addr*slistのstruct)。
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
値0が返される成功の上と、そして、失敗の上では、値-1を返します、そして、errnoはそれに従って、用意ができています。
The s argument identifies the socket.
s議論はソケットを特定します。
The interface argument holds the local IP address of the interface.
インタフェース議論はインタフェースのローカルアイピーアドレスを保持します。
The group argument holds the IP multicast address of the group.
グループ議論はグループのIPマルチキャストアドレスを保持します。
Thaler, et al. Informational [Page 8] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [8ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
The fmode argument identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
fmode議論はフィルタモードを特定します。 この分野の値は、MCAST_INCLUDEかMCAST_EXCLUDEのどちらかでなければなりません。(そのEXCLUDEは<netinet/in.h>で同様に定義されます)。
The numsrc argument holds the number of source addresses in the slist array.
numsrc議論はslist配列における、ソースアドレスの数を保持します。
The slist argument points to an array of IP addresses of sources to include or exclude depending on the filter mode.
slist議論はフィルタモードに依存する含んでいるか、または除くソースのIPアドレスの勢ぞろいを示します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when the operation would exceed the maximum.
操作が最大を超えているだろうというとき、実装がソースフィルタのソースの最大数で指し値するなら、ENOBUFSは発生しています。
4.2.2. Get Source Filter
4.2.2. フィルタをソースに手に入れてください。
#include <netinet/in.h>
#<netinet/in.h>を含めてください。
int getipv4sourcefilter(int s, struct in_addr interface,
struct in_addr group, uint32_t *fmode,
uint32_t *numsrc, struct in_addr *slist);
int getipv4sourcefilter(int s、_addrインタフェースのstruct、_addrグループにおけるstruct、uint32_t*fmode、uint32_t*numsrc、_addr*slistのstruct)。
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
値0が返される成功の上と、そして、失敗の上では、値-1を返します、そして、errnoはそれに従って、用意ができています。
The s argument identifies the socket.
s議論はソケットを特定します。
The interface argument holds the local IP address of the interface.
インタフェース議論はインタフェースのローカルアイピーアドレスを保持します。
The group argument holds the IP multicast address of the group.
グループ議論はグループのIPマルチキャストアドレスを保持します。
The fmode argument points to an integer that will contain the filter mode on a successful return. The value of this field will be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
fmode議論はうまくいっているリターンにフィルタモードを含む整数を示します。 この分野の値は、MCAST_INCLUDEかEXCLUDEのどちらかにMCAST_なるでしょう。(そのEXCLUDEは<netinet/in.h>で同様に定義されます)。
On input, the numsrc argument holds the number of source addresses that will fit in the slist array. On output, the numsrc argument will hold the total number of sources in the filter.
入力のときに、numsrc議論はslist配列をうまくはめ込むソースアドレスの数を開催します。 出力のときに、numsrc議論はフィルタのソースの総数を開催するでしょう。
The slist argument points to buffer into which an array of IP addresses of included or excluded (depending on the filter mode) sources will be written. If numsrc was 0 on input, a NULL pointer may be supplied.
slist議論は含まれているか除かれた(フィルタモードに依存する)ソースのIPアドレスの勢ぞろいが書かれているバッファを示します。 numsrcが入力での0であったなら、NULL指針を供給するかもしれません。
Thaler, et al. Informational [Page 9] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [9ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, numsrc holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションがあらかじめソース・リストのサイズを知らないなら、合理的な推測を(例えば、0)にすることができます、そして、numsrcが完成のときに、より大きい値を開催するなら、十分大きいバッファで操作は繰り返すことができます。
That is, on return, numsrc is always updated to be the total number of sources in the filter, while slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original numsrc value and the total number of sources in the filter.
すなわち、リターンのときに、フィルタのソースの総数になるようにいつもnumsrcをアップデートします、slistは合うのと同じくらい多くのソースアドレスを保持するでしょうが、サイズが元のnumsrc値として通用した配列の最小限とフィルタのソースの総数まで。
5. Protocol-Independent Multicast Source Filter APIs
5. プロトコルから独立しているマルチキャストソースフィルタAPI
Protocol-independent functions are provided for join and leave operations so that an application may pass a sockaddr_storage structure obtained from calls such as getaddrinfo() [1] as the group to join. For example, an application can resolve a DNS name (e.g., NTP.MCAST.NET) to a multicast address which may be either IPv4 or IPv6, and may easily join and leave the group.
機能が提供されるプロトコル独立者は、アプリケーションが接合するというグループとしてのgetaddrinfo()[1]などの要求から得られたsockaddr_格納構造を通過できるように、操作に参加して、残します。 例えば、アプリケーションは、IPv4かIPv6のどちらかであるかもしれなく、容易に接合するかもしれないマルチキャストアドレスにDNS名(例えば、NTP.MCAST.NET)を決議して、仲間から抜けることができます。
5.1. Basic (Delta-based) API
5.1. 基本的な(デルタベースの)API
The reception of multicast packets is controlled by the setsockopt() options summarized below. An error of EOPNOTSUPP is returned if these options are used with getsockopt().
マルチキャストパケットのレセプションは以下へまとめられたsetsockopt()オプションで制御されます。 これらのオプションがgetsockopt()と共に使用されるなら、EOPNOTSUPPの誤りは返されます。
The following structures are used by both the Any-Source Multicast and the Source-Specific Multicast API: #include <netinet/in.h>
以下の構造はAny-ソースMulticastとSource特有のMulticast APIの両方によって使用されます: #<netinet/in.h>を含めてください。
struct group_req {
uint32_t gr_interface; /* interface index */
struct sockaddr_storage gr_group; /* group address */
};
structグループ_req uint32_t gr_インタフェース; /*インタフェースインデックス*/struct sockaddr_ストレージgr_グループ;/*グループアドレス*/。
struct group_source_req {
uint32_t gsr_interface; /* interface index */
struct sockaddr_storage gsr_group; /* group address */
struct sockaddr_storage gsr_source; /* source address */
};
structグループ_ソース_req uint32_t gsr_インタフェース; /*インタフェースインデックス*/struct sockaddr_ストレージgsr_グループ; /*グループアドレス*/struct sockaddr_ストレージgsr_ソース;/*ソースアドレス*/。
The sockaddr_storage structure is defined in RFC 3493 [1] to be large enough to hold either IPv4 or IPv6 address information.
sockaddr_格納構造は、IPv4かIPv6アドレス情報のどちらかを保持できるくらい大きくなるようにRFC3493[1]で定義されます。
The rules for generating errors are the same as those given in Section 5.1.3.
誤りを生成するための規則はセクション5.1.3で与えられたものと同じです。
Thaler, et al. Informational [Page 10] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [10ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
5.1.1. Any-Source Multicast API
5.1.1. いくらか、-、ソース、マルチキャストAPI
Socket option Argument type MCAST_JOIN_GROUP struct group_req MCAST_BLOCK_SOURCE struct group_source_req MCAST_UNBLOCK_SOURCE struct group_source_req MCAST_LEAVE_GROUP struct group_req
ソケットオプションArgumentは_MCAST_JOIN_GROUP structグループ_req MCAST_BLOCK_SOURCE structグループ_ソース_req MCAST_UNBLOCK_SOURCE structグループ_ソース_req MCAST_LEAVE_GROUP structグループreqをタイプします。
MCAST_JOIN_GROUP and MCAST_LEAVE_GROUP are used to join and leave an any-source group.
MCAST_JOIN_GROUPとMCAST_LEAVE_GROUPが接合して、いなくなるのに使用される、いくらか、-、ソース、分類してください。
MCAST_BLOCK_SOURCE can be used to block data from a given source to a given group (e.g., if the user "mutes" that source), and MCAST_UNBLOCK_SOURCE can be used to undo this (e.g., if the user then "unmutes" the source).
当然のことのソースから当然のことのグループまでデータを妨げるのにMCAST_BLOCK_SOURCEを使用できます、そして、(例えば、ユーザがそのソースに「音を消す」なら)これを元に戻すのにMCAST_UNBLOCK_SOURCEを使用できます(例えば、次に、ユーザがソースを"「非-無言」"であるなら)。
5.1.2. Source-Specific Multicast API
5.1.2. ソース特有のマルチキャストAPI
Socket option Argument type MCAST_JOIN_SOURCE_GROUP struct group_source_req MCAST_LEAVE_SOURCE_GROUP struct group_source_req MCAST_LEAVE_GROUP struct group_req
ソケットオプションArgumentは_MCAST_JOIN_SOURCE_GROUP structグループ_ソース_req MCAST_LEAVE_SOURCE_GROUP structグループ_ソース_req MCAST_LEAVE_GROUP structグループreqをタイプします。
MCAST_JOIN_SOURCE_GROUP and MCAST_LEAVE_SOURCE_GROUP are used to join and leave a source-specific group.
MCAST_JOIN_SOURCE_GROUPとMCAST_LEAVE_SOURCE_GROUPは、ソース特有のグループに加わって、出るのに使用されます。
MCAST_LEAVE_GROUP is supported, as a convenience, to drop all sources which have been joined for a particular group and interface. The operations are the same as if the socket had been closed.
MCAST_LEAVE_GROUPは、特定のグループとインタフェースが一緒に楽しまれたすべてのソースを下げるために便利としてサポートされます。 まるでソケットが閉じられたかのように操作は同じです。
5.2. Advanced (Full-state) API
5.2. 高度な(完全な状態)API
Implementations may exist that use ioctl() for this API, and for historical purposes, the ioctl() API is documented in Appendix A. The preferred API uses the new functions described below.
このAPIにioctl()を使用する実装は存在するかもしれません、そして、歴史的な目的のために、ioctl()APIはAppendix A.に記録されます。都合のよいAPIは以下で説明された新しい機能を使用します。
5.2.1. Set Source Filter
5.2.1. セットソースフィルタ
#include <netinet/in.h>
#<netinet/in.h>を含めてください。
int setsourcefilter(int s, uint32_t interface,
struct sockaddr *group, socklen_t grouplen,
uint32_t fmode, uint_t numsrc,
struct sockaddr_storage *slist);
int setsourcefilter(int s、uint32_tインタフェース、struct sockaddr*グループは_t grouplen、uint32_t fmode、uint_t numsrc、struct sockaddr_ストレージ*slistをsocklenします)。
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
値0が返される成功の上と、そして、失敗の上では、値-1を返します、そして、errnoはそれに従って、用意ができています。
Thaler, et al. Informational [Page 11] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [11ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
The s argument identifies the socket.
s議論はソケットを特定します。
The interface argument holds the interface index of the interface.
インタフェース議論はインタフェースのインタフェースインデックスを保持します。
The group argument points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP multicast address of the group.
グループ議論はグループのIPマルチキャストアドレスを保持する構造のsockaddr_(IPv4のための)かsockaddr_in6構造(IPv6のための)のどちらかを示します。
The grouplen argument gives the length of the sockaddr_in or sockaddr_in6 structure.
議論がsockaddr_の長さを与えるか、またはsockaddr_in6が構造化するgrouplen。
The fmode argument identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
fmode議論はフィルタモードを特定します。 この分野の値は、MCAST_INCLUDEかMCAST_EXCLUDEのどちらかでなければなりません。(そのEXCLUDEは<netinet/in.h>で同様に定義されます)。
The numsrc argument holds the number of source addresses in the slist array.
numsrc議論はslist配列における、ソースアドレスの数を保持します。
The slist argument points to an array of IP addresses of sources to include or exclude depending on the filter mode.
slist議論はフィルタモードに依存する含んでいるか、または除くソースのIPアドレスの勢ぞろいを示します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when the operation would exceed the maximum.
操作が最大を超えているだろうというとき、実装がソースフィルタのソースの最大数で指し値するなら、ENOBUFSは発生しています。
5.2.2. Get Source Filter
5.2.2. フィルタをソースに手に入れてください。
#include <netinet/in.h>
#<netinet/in.h>を含めてください。
int getsourcefilter(int s, uint32_t interface,
struct sockaddr *group, socklen_t grouplen,
uint32_t fmode, uint_t *numsrc,
struct sockaddr_storage *slist);
int getsourcefilter(int s、uint32_tインタフェース、struct sockaddr*グループは_t grouplen、uint32_t fmode、uint_t*numsrc、struct sockaddr_ストレージ*slistをsocklenします)。
On success the value 0 is returned, and on failure, the value -1 is returned and errno is set accordingly.
値0が返される成功の上と、そして、失敗の上では、値-1を返します、そして、errnoはそれに従って、用意ができています。
The s argument identifies the socket.
s議論はソケットを特定します。
The interface argument holds the local IP address of the interface.
インタフェース議論はインタフェースのローカルアイピーアドレスを保持します。
The group argument points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP multicast address of the group.
グループ議論はグループのIPマルチキャストアドレスを保持する構造のsockaddr_(IPv4のための)かsockaddr_in6構造(IPv6のための)のどちらかを示します。
Thaler, et al. Informational [Page 12] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [12ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
The fmode argument points to an integer that will contain the filter mode on a successful return. The value of this field will be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
fmode議論はうまくいっているリターンにフィルタモードを含む整数を示します。 この分野の値は、MCAST_INCLUDEかEXCLUDEのどちらかにMCAST_なるでしょう。(そのEXCLUDEは<netinet/in.h>で同様に定義されます)。
On input, the numsrc argument holds the number of source addresses that will fit in the slist array. On output, the numsrc argument will hold the total number of sources in the filter.
入力のときに、numsrc議論はslist配列をうまくはめ込むソースアドレスの数を開催します。 出力のときに、numsrc議論はフィルタのソースの総数を開催するでしょう。
The slist argument points to buffer into which an array of IP addresses of included or excluded (depending on the filter mode) sources will be written. If numsrc was 0 on input, a NULL pointer may be supplied.
slist議論は含まれているか除かれた(フィルタモードに依存する)ソースのIPアドレスの勢ぞろいが書かれているバッファを示します。 numsrcが入力での0であったなら、NULL指針を供給するかもしれません。
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, numsrc holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションがあらかじめソース・リストのサイズを知らないなら、合理的な推測を(例えば、0)にすることができます、そして、numsrcが完成のときに、より大きい値を開催するなら、十分大きいバッファで操作は繰り返すことができます。
That is, on return, numsrc is always updated to be the total number of sources in the filter, while slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original numsrc value and the total number of sources in the filter.
すなわち、リターンのときに、フィルタのソースの総数になるようにいつもnumsrcをアップデートします、slistは合うのと同じくらい多くのソースアドレスを保持するでしょうが、サイズが元のnumsrc値として通用した配列の最小限とフィルタのソースの総数まで。
6. Security Considerations
6. セキュリティ問題
Although source filtering can help to combat denial-of-service attacks, source filtering alone is not a complete solution, since it does not provide protection against spoofing the source address to be an allowed source. Multicast routing protocols which use reverse- path forwarding based on the source address, however, do provide some natural protection against spoofing the source address, since if a router receives a packet on an interface other than the one toward the "real" source, it will drop the packet. However, this still does not provide any guarantee of protection.
ソースフィルタリングは、サービス不能攻撃と戦うのを助けることができますが、唯一のソースフィルタリングは完全解ではありません、ソースアドレスが許容ソースであると偽造することに対する保護を提供しないので。 しかしながら、ソースアドレスに基づく逆経路推進を使用するマルチキャストルーティング・プロトコルはソースアドレスを偽造しないように何らかのナチュラルプロテクションを提供します、ルータが「本当」のソースに向かったもの以外のインタフェースでパケットを受けると、パケットを下げるので。 しかしながら、これはまだ保護のどんな保証も提供していません。
7. Acknowledgments
7. 承認
This document was updated based on feedback from the IETF's IDMR and MAGMA Working Groups, and the Austin Group. Wilbert de Graaf also provided many helpful comments.
IETFのIDMRとMAGMA Working Groupsからのフィードバック、およびオースチンGroupに基づいてこのドキュメントをアップデートしました。 また、Wilbert deグラーフは多くの役に立つコメントを提供しました。
Thaler, et al. Informational [Page 13] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [13ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
8. Appendix A: Use of ioctl() for full-state operations
8. 付録A: ioctl()の完全な州の操作の使用
The API defined here is historic, but is documented here for informational purposes since it is implemented by multiple platforms. The new functions defined earlier in this document should now be used instead.
ここで定義されたAPIは、歴史的ですが、それが複数のプラットホームによって実装されるので、情報の目的のためにここに記録されます。より早く定義された新しい機能は現在、代わりに本書では使用されるべきです。
Retrieving the source filter for a given group cannot be done with getsockopt() on some existing platforms, since the group and interface must be passed down in order to retrieve the correct filter, and getsockopt only supports an output buffer. This can, however, be done with an ioctl(), and hence for symmetry, both gets and sets are done with an ioctl.
与えられたグループのためにいくつかの既存のプラットホームのgetsockopt()でソースフィルタを検索できません、getsockoptが正しいフィルタを検索するためにグループとインタフェースを伝えなければならなくて、出力バッファをサポートするだけであるので。 しかしながら、ioctl()、およびしたがって、対称のためにこれができます、そして、両方が得られます、そして、ioctlでセットをします。
8.1. IPv4 Options
8.1. IPv4オプション
The following are defined in <sys/sockio.h>:
以下は<sys/sockio.h>で定義されます:
o ioctl() SIOCGIPMSFILTER: to retrieve the list of source
addresses that comprise the source filter along with the
current filter mode.
o ioctl() SIOCGIPMSFILTER: 電流に伴うソースフィルタを包括するソースアドレスのリストを検索するには、モードをフィルターにかけてください。
o ioctl() SIOCSIPMSFILTER: to set or modify the source filter
content (e.g., unicast source address list) or mode (exclude or
include).
o ioctl() SIOCSIPMSFILTER: ソースを設定するか、または変更するには、内容(例えば、ユニキャストソース住所録)かモード(除くか、または含んでいる)をフィルターにかけてください。
Ioctl option Argument type SIOCGIPMSFILTER struct ip_msfilter SIOCSIPMSFILTER struct ip_msfilter
IoctlオプションArgumentはSIOCGIPMSFILTER struct ip_msfilter SIOCSIPMSFILTER struct ip_msfilterをタイプします。
struct ip_msfilter {
struct in_addr imsf_multiaddr; /* IP multicast address of group */
struct in_addr imsf_interface; /* local IP address of interface */
uint32_t imsf_fmode; /* filter mode */
uint32_t imsf_numsrc; /* number of sources in src_list */
struct in_addr imsf_slist[1]; /* start of source list */
};
_t imsf_numsrc; _addr imsf_slist[1]のsrc_リスト*/structのソースの/*数;ソース・リスト*/の/*始まりが_addr imsf_multiaddrのstruct; _addr imsf_インタフェースのグループ*/structの/*IPマルチキャストアドレス; /*ローカルアイピーが_インタフェース*/uint32t imsf_fmode; /*フィルタモード*/uint32を扱うstruct ip_msfilter。
#define IP_MSFILTER_SIZE(numsrc) \ (sizeof(struct ip_msfilter) - sizeof(struct in_addr) \ + (numsrc) * sizeof(struct in_addr))
#IP_MSFILTER_SIZE(numsrc)\を定義してください。(sizeof(struct ip_msfilter)--sizeof(_addrのstruct)\+(numsrc)*sizeof(_addrのstruct))
The imsf_fmode mode is a 32-bit integer that identifies the filter mode. The value of this field must be either MCAST_INCLUDE or MCAST_EXCLUDE, which are likewise defined in <netinet/in.h>.
imsf_fmodeモードはフィルタモードを特定する32ビットの整数です。 この分野の値は、MCAST_INCLUDEかMCAST_EXCLUDEのどちらかでなければなりません。(そのEXCLUDEは<netinet/in.h>で同様に定義されます)。
Thaler, et al. Informational [Page 14] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [14ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
The structure length pointed to must be at least IP_MSFILTER_SIZE(0) bytes long, and the imsf_numsrc parameter should be set so that IP_MSFILTER_SIZE(imsf_numsrc) indicates the buffer length.
示された構造の長さが少なくともIP_MSFILTER_SIZE(0)バイト長であるに違いなく、imsf_numsrcパラメタが設定されるべきであるので、IP_MSFILTER_SIZE(imsf_numsrc)はバッファ長を示します。
If the implementation imposes a limit on the maximum number of sources in a source filter, ENOBUFS is generated when a set operation would exceed the maximum.
集合演算が最大を超えているだろうというとき、実装がソースフィルタのソースの最大数で指し値するなら、ENOBUFSは発生しています。
The result of a get operation (SIOCGIPMSFILTER) will be that the imsf_multiaddr and imsf_interface fields will be unchanged, while imsf_fmode, imsf_numsrc, and as many source addresses as fit will be filled into the application's buffer.
aの結果はそれがimsf_multiaddrであるつもりであったなら操作(SIOCGIPMSFILTER)を得ます、そして、imsf_インタフェース分野は変わりがなくなるでしょう、imsf_fmode、imsf_numsrc、および合うのと同じくらい多くのソースアドレスがアプリケーションのバッファの中にいっぱいにされるでしょうが。
If the application does not know the size of the source list beforehand, it can make a reasonable guess (e.g., 0), and if upon completion, the imsf_numsrc field holds a larger value, the operation can be repeated with a large enough buffer.
アプリケーションがあらかじめソース・リストのサイズを知らないなら、合理的な推測を(例えば、0)にすることができます、そして、imsf_numsrc分野が完成のときに、より大きい値を開催するなら、十分大きいバッファで操作は繰り返すことができます。
That is, on return from SIOCGIPMSFILTER, imsf_numsrc is always updated to be the total number of sources in the filter, while imsf_slist will hold as many source addresses as fit, up to the minimum of the array size passed in as the original imsf_numsrc value and the total number of sources in the filter.
すなわち、SIOCGIPMSFILTERからのリターンのときに、フィルタのソースの総数になるようにいつもimsf_numsrcをアップデートします、imsf_slistは合うのと同じくらい多くのソースアドレスを保持するでしょうが、サイズが元のimsf_numsrc値として通用した配列の最小限とフィルタのソースの総数まで。
8.2. Protocol-Independent Options
8.2. プロトコルから独立しているオプション
The following are defined in <sys/sockio.h>:
以下は<sys/sockio.h>で定義されます:
o ioctl() SIOCGMSFILTER: to retrieve the list of source addresses
that comprise the source filter along with the current filter
mode.
o ioctl() SIOCGMSFILTER: 電流に伴うソースフィルタを包括するソースアドレスのリストを検索するには、モードをフィルターにかけてください。
o ioctl() SIOCSMSFILTER: to set or modify the source filter
content (e.g., unicast source address list) or mode (exclude or
include).
o ioctl() SIOCSMSFILTER: ソースを設定するか、または変更するには、内容(例えば、ユニキャストソース住所録)かモード(除くか、または含んでいる)をフィルターにかけてください。
Ioctl option Argument type SIOCGMSFILTER struct group_filter SIOCSMSFILTER struct group_filter
IoctlオプションArgumentタイプSIOCGMSFILTER structグループ_フィルタSIOCSMSFILTER structグループ_フィルタ
struct group_filter {
uint32_t gf_interface; /* interface index */
struct sockaddr_storage gf_group; /* multicast address */
uint32_t gf_fmode; /* filter mode */
uint32_t gf_numsrc; /* number of sources */
struct sockaddr_storage gf_slist[1]; /* source address */
};
structグループ_はuint32_t gf_インタフェース; /*インタフェースインデックス*/struct sockaddr_ストレージgf_グループ; _/*マルチキャストアドレス*/uint32t gf_fmode; _/*フィルタモード*/uint32t gf_numsrc; ソース*/struct sockaddr_ストレージgf_slist[1]の/*数; /*ソースアドレス*/をフィルターにかけます。
Thaler, et al. Informational [Page 15] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [15ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
#define GROUP_FILTER_SIZE(numsrc) \
(sizeof(struct group_filter) - sizeof(struct sockaddr_storage) \
+ (numsrc) * sizeof(struct sockaddr_storage))
#GROUP_FILTER_SIZE(numsrc)\を定義してください。(sizeof(structグループ_フィルタ)--sizeof(struct sockaddr_ストレージ)\+(numsrc)*sizeof(struct sockaddr_ストレージ))
The imf_numsrc field is used in the same way as described for imsf_numsrc above.
imf_numsrc分野はimsf_numsrcのための上の説明されるのと同じように使用されます。
9. Normative References
9. 引用規格
[1] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003.
[1] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャンとJ.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[2] IEEE Std. 1003.1-2001 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 6, December 2001.
ISO/IEC 9945:2002. http://www.opengroup.org/austin
[2] IEEE Std。 1003.1-2001、情報技術の規格--携帯用のオペレーティングシステムインタフェース(POSIX)。 グループ規格を開いてください: 2001年12月に仕様、問題6を基礎づけてください。 ISO/IEC9945: 2002 http://www.opengroup.org/austin
10. Informative References
10. 有益な参照
[3] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[3] カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月」。
[4] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", Work in Progress, December 2003.
[4] ビーダとR.とL.コスタ、「IPv6"のためのマルチキャストリスナー発見バージョン2(MLDv2)、処理中の作業、2003年12月。」
Thaler, et al. Informational [Page 16] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [16ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
11. Authors' Addresses
11. 作者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デーヴターレルマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Bill Fenner 75 Willow Road Menlo Park, CA 94025
メンローパーク、ビル・フェナー75・柳のRoadカリフォルニア 94025
Phone: +1 650 867 6073 EMail: fenner@research.att.com
以下に電話をしてください。 +1 6073年の650 867メール: fenner@research.att.com
Bob Quinn IP Multicast Initiative (IPMI) Stardust.com 1901 S. Bascom Ave. #333 Campbell, CA 95008
マルチキャストイニシアチブ(IPMI)Stardust.com1901秒間ボブクインIPバスコムAve。 #333 キャンベル、カリフォルニア 95008
Phone: +1 408 879 8080 EMail: rcq@ipmulticast.com
以下に電話をしてください。 +1 8080年の408 879メール: rcq@ipmulticast.com
Thaler, et al. Informational [Page 17] RFC 3678 Multicast Source Filter API January 2004
ターレル、他 [17ページ]情報のRFC3678マルチキャストソースフィルタAPI2004年1月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Thaler, et al. Informational [Page 18]
ターレル、他 情報[18ページ]
一覧
スポンサーリンク
