JP3969395B2 - ネットワーク・システムおよび端末設定方法 - Google Patents

ネットワーク・システムおよび端末設定方法 Download PDF

Info

Publication number
JP3969395B2
JP3969395B2 JP2004012756A JP2004012756A JP3969395B2 JP 3969395 B2 JP3969395 B2 JP 3969395B2 JP 2004012756 A JP2004012756 A JP 2004012756A JP 2004012756 A JP2004012756 A JP 2004012756A JP 3969395 B2 JP3969395 B2 JP 3969395B2
Authority
JP
Japan
Prior art keywords
address
server
client
mac address
rarp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004012756A
Other languages
English (en)
Other versions
JP2005210265A (ja
Inventor
弥 近藤
健一 北村
樂 白澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2004012756A priority Critical patent/JP3969395B2/ja
Priority to US11/039,481 priority patent/US20050180439A1/en
Publication of JP2005210265A publication Critical patent/JP2005210265A/ja
Application granted granted Critical
Publication of JP3969395B2 publication Critical patent/JP3969395B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

この発明は、未知のIPアドレスを容易に解決するネットワーク・システムおよび端末設定方法に関する。
現在では、複数の端末が接続されたネットワーク・システムが家庭にまで広く普及し、これによって、各部屋で、インターネットを経由するアプリケーションを利用したり、動画や音声を視聴したりすることができる。通常、こうしたネットワーク・システムにおいては、各端末間のパケット送受信がIP(Internet Protocol)によって、すなわち、IPアドレスを用いて行われている。従って、ネットワーク・システムの各端末は、通信を行う相手の端末のIPアドレスを事前に知っておく必要がある。
また、各端末は、実際のイーサネット(登録商標)を介した通信においては、宛先端末のMAC(Media Access Control)アドレスにイーサネットフレームを転送しなければならず、そのために、宛先端末については、当該フレームの転送前に、IPアドレスのみならずMACアドレスを知っておく必要がある。IPアドレスが既知で、MACアドレスが分からない場合に、そのMACアドレスの取得をするプロトコルがARP(Address Resolution Protocol)である。MACアドレスは、各端末のNIC(Network Interface Card)等に対応する物理アドレスであり、メーカー番号とそのメーカーの固有番号からなるユニークな番号である。
またさらに、ディスクレス・ワークステーションのような端末は、自身のIPアドレスを保持していないため、このような端末では、起動時に、IPアドレスを自身のMACアドレスから取得する。これに用いられるプロトコルがRARP(Reverse ARP)である。ARPはRFC(Request for Comments)826で、RARPはRFC903でそれぞれ規定されている。
ここで、ARPとRARPの概要について、図5ないし図8を参照して説明する。図5は、ネットワーク・システムのネットワーク構成を表す略線図である。このネットワーク・システムは、1つのネットワークと、これに接続された4つの端末(端末100、端末110、端末120、および端末130)から構成される。また、各端末は、ARPテーブル(ARPキャッシュ)を備えており、ネットワークは有線のみならず、無線の場合もある。
さらに、図5には、各端末に対応するMACアドレスとIPアドレスが示されている。端末100のMACアドレスはMAC−100、IPアドレスはIP−100である。実際のMACアドレスは、イーサネットの場合6バイトのバイナリデータであり、IPアドレスは、IPv4の場合4バイトのバイナリデータであるが、本明細書では、MAC−100等の便宜的な表記を用いる。
端末110のMACアドレスはMAC−110、IPアドレスはIP−110であり、端末120のMACアドレスはMAC−120、IPアドレスはIP−120である。また、端末130のMACアドレスはMAC−130、IPアドレスはIP−130である。
ここで、図5に示すネットワーク・システムにおいて、端末100から端末130にパケットを送信する場合について考える。また、端末100はこの時点で、端末130のIPアドレスを知っているが、MACアドレスを知らないものとする。端末100が端末130にパケットを送信する場合、前述のように端末130のMACアドレスを指定する必要がある。そこで、端末100は、最初に、ネットワーク上の端末全てに対して、端末130のMACアドレスを求めるためのARP要求パケットを送信する。これは、いわゆるブロードキャストと呼ばれるものであり、有線LAN(Local Area Network)の場合は、原則的に、1つのセグメント上の端末が送信範囲であり、無線LANの場合は、所定のエリア内の端末が送信範囲となる。
図6Aには、上記ARP要求において端末100が送信するイーサネットフレーム200が示されている。イーサネットフレーム200は、宛先MACアドレス、送信元MACアドレス、およびIPパケットを含み、ここでは、IPパケットが上述のARP要求パケットに対応する。また、フレーム内の各項目は、説明に必要なものを示しているに過ぎず、厳密なフレームのレイアウトを示すものではない。イーサネットフレーム200内には、(OSI(Open Systems Interconnection)参照モデルにおける)ネットワーク層で参照されるMACアドレス(すなわち、IPパケット内のMACアドレス)と、それより下位の層で参照されるMACアドレスとがあるが、ここでは、前者をMACアドレス2(宛先MACアドレス2、送信元MACアドレス2)、後者をMACアドレス1(宛先MACアドレス1、送信元MACアドレス1)と称することとする。
イーサネットフレーム200の宛先MACアドレス1には、、全てのビットを1とした値(F〜F)が設定される。これによって、当該フレームが上記ネットワーク上にブロードキャストされる。また、送信元MACアドレス1には端末100のMACアドレスであるMAC−100が設定される。IPパケットのプロトコルタイプは、ARP要求を示すように設定される。ここでは簡略的な記載がされているが、実際は、プロトコルビットと動作ビットによってARP要求であることが示される。その他、送信元MACアドレス2には、送信元MACアドレス1と同様、端末100のMACアドレスであるMAC−100が設定され、宛先IPアドレスには、IP−130が、送信元IPアドレスにはIP−100が設定される。
ブロードキャストされた上記イーサネットフレーム200は、端末110、端末120、および端末130で受信される。図5の点線矢印140は、このブロードキャストを示している。各端末は、イーサネットフレーム200を受信すると、イーサネットフレーム200の宛先IPアドレスと自身のIPアドレスが一致しているかどうか判定し、一致している場合は、ARP応答パケットを送信元IPアドレスに向けて送信する。これは、図5の点線矢印150によって示されている。この場合、イーサネットフレーム200の宛先IPアドレスは、端末130のものであるため、端末130だけがARP応答パケットを端末100に送信する。また、このとき、端末130は、少なくとも送信元MACアドレス1に設定されたデータにより、端末100のMACアドレスを把握する。
それととともに、端末130は、ARPテーブル190に図6Bに示すような、MACアドレスとIPアドレスの対205を登録する。これによって、端末130は、その後、端末100にパケットを送信する場合、ARPテーブル190を参照して端末100のMACアドレスを取得すれば良く、今回の端末100のように、ARP要求パケットを端末100に送信する必要がない。また、ARPテーブル190の内容は、各端末のIPアドレスの更新に対応し、あるいは不使用のエントリーを整理する意味から、所定間隔でクリアされることが好ましい。
一方、イーサネットフレーム200の宛先IPアドレスと自身のIPアドレスが一致していない場合、すなわち、端末110と端末120では、そのフレームを破棄する。
端末130が端末100に送信するのは、図6Cに示すようなARP応答パケットを含むイーサネットフレーム210である。宛先MACアドレス1および宛先MACアドレス2には、MAC−100が設定され、送信元MACアドレス1および送信元MACアドレス2には端末130のMACアドレスであるMAC−130が設定される。IPパケットのプロトコルタイプは、ARP応答を示すように設定される。これは、図6Aと同様、簡略的な記載である。また、宛先IPアドレスには、IP−100が、送信元IPアドレスにはIP−130が設定される。端末100がこのフレームを受け取ることによって、端末130のMACアドレスがMAC−130であることが分かる。
端末100は、それととともに、ARPテーブル160に、図6Dに示すような、MACアドレスとIPアドレスの対215を登録する。これによって、端末100は、その後、再び端末130にパケットを送信する場合、ARPテーブル160を参照して端末130のMACアドレスを取得すれば良く、送信のたびに上述のようなARP要求パケットを送信する必要がない。
次に、RARPについて説明する。同じ図4を参照するが、ここでは、端末130をRARPサーバと仮定する。また、RARPサーバは、図7に示すようなARPテーブル220を備えているものとする。ARPテーブル220には、端末100、端末110、および端末120のMACアドレスについて、それぞれ対応するIPアドレスが記憶されている。
RARP要求パケットは、ディスクレス・ワークステーションなどが、自身のIPアドレスを求めるために送信するパケットである。ディスクレス・ワークステーションは、ハードディスク等の記録手段を持たないために自身のIPアドレスを保持できず、IPを用いた通信を行う場合には、他の端末の記録手段から自身のIPアドレスを取得する必要が生じる。一方、自身の端末を識別するための識別子が必要とされるが、これは、NIC等から得られるMACアドレスが用いられる。
図5に示す端末100をディスクレス・ワークステーションとすると、例えば、端末100の起動時に、RARP要求パケット(イーサネットフレーム)がブロードキャストされる。このフレームは図5の点線矢印140のように、ネットワーク上の各端末に送信される。ブロードキャストを行っているのは、この時点では、RARPサーバがどの端末かを特定することができないからである。
図8Aには、RARP要求パケットを含むイーサネットフレーム230が示されている。イーサネットフレーム230の宛先MACアドレス1には、このフレームをブロードキャストするために、全てのビットを1とした値(F〜F)が設定される。また、送信元MACアドレス1には端末100のMACアドレスであるMAC−100が設定される。IPパケットのプロトコルタイプは、RARP要求を示すように設定される。上記同様、ここでは簡略的に記載されている。その他、送信元MACアドレス2には、送信元MACアドレス1と同様、端末100のMACアドレスであるMAC−100が設定され、宛先IPアドレス、および送信元IPアドレスには値が設定されない。
RARPサーバである端末130は、このイーサネットフレーム230を受信すると、プロトコルタイプを参照して自身が処理すべきフレームであると判断し、RARP応答パケットを生成して、それを端末100に返信する。他の端末では、RARPサーバのプロセスが稼働していないので、RARP要求パケットを受信した場合は、そのパケットを破棄する。
図8Bには、端末130が端末100に送信する、RARP応答パケットを含んだイーサネットフレーム240が示されている。イーサネットフレーム240の宛先MACアドレス1、および宛先MACアドレス2には、MAC−100が設定され、送信元MACアドレス1、および送信元MACアドレス2には、MAC−130が設定される。IPパケットのプロトコルタイプは、RARP応答を示すように設定される。上記同様、ここでは簡略的に記載されている。端末130は、RARP要求パケット内の送信元MACアドレス2等の内容を参照して、それに対応するIPアドレスをARPテーブル220から検索し、求めたIPアドレスを、RARP応答パケットの、宛先IPアドレスに設定する。従って、宛先IPアドレスにはIP−100が設定される。また、送信元IPアドレスにはIP−130が設定される。
端末100は、このRARP応答パケットを受信し、宛先IPアドレスを参照することによって、自身のIPアドレスを知ることができる。RARP応答パケットの送信は、図5では、点線矢印150に対応する。
RARPを実装する端末は、その必要性から少数であるが、ARPはほとんどの端末で必要とされる。上述のように、パケットを送信する宛先端末のIPアドレスが分かっていれば、ARPを利用して、その端末のMACアドレスが得られる。そこで、一般的なサーバ・クライアント型の家庭内ネットワーク・システムでは、端末をネットワーク・システムで利用可能とするために、各端末について所定の作業が必要となる。例えば、クライアントの場合は以下のような作業である。
(1)そのクライアントのIPアドレスを設定する。
(2)そのクライアントに、パケットの送信を予定する他の端末(サーバを含む)のIPアドレスを登録する。
これらの処理の後、当該クライアントは、他の端末のIPアドレスを指定して当該他の端末にパケットの送信を行う。例えば、サーバに対して要求がある場合は、そのサーバのIPアドレスをIPパケットのヘッダ部に指定して送信する。
しかしながら、クライアントを追加するたびにこれらの作業を行うことは非常に煩雑であり、これらの設定に戸惑い、またはミスを犯すユーザも多い。こうした問題を解決するために、UPnP(Universal Plug and Play)のプロトコルを利用するという方法が考えられる。UPnPとは、IPネットワークに接続されるあらゆるデバイスが互いに自動認識できるように、所定のメッセージを交換してそのデバイスに関する情報(上記の例ではIPアドレス)をやり取りする仕組みである。
また、特許文献1には、UPnPの実装された機器(以下、UPnP機器と称する)と、IEEE(Institute of Electrical and Electronics Engineers)1394高速シリアルバスに接続された機器(以下、AV/C機器と称する)とが接続されたネットワーク・システムにおいて、コマンドの変換を行うことによって、UPnP機器がAV/C機器を制御することができる情報処理装置が開示されている。
特開2003−46535号公報
このような情報処理装置を導入すれば、UPnP機器から、オーディオ機器やビデオ機器等のAV/C機器に指令を送出して、ホーム・シアター等のネットワーク・システムを構築することができる。
しかしながら、上記のようなネットワーク・システムにおいては、UPnP機器やシステムの構成を大幅に変更しなければならないという問題がある。また、発売時期の古い端末などではUPnPが実装されておらず、ネットワーク・システムに接続する端末がUPnP機器であることを前提とすると、これらを利用することができないという問題もある。
さらに、1つのネットワーク・システムに接続されるという前提で販売される複数の端末のセットについては、その全ての端末にUPnPを実装しておくという方法が考えられるが、コスト面(例えば、UPnPに関連する部分の開発や相互接続テストに要する工数や、モジュールの増加等によるメモリ容量の増大に起因するコストの増加)から好ましい方法であるとは言い難い。
従って、この発明の目的は、大幅な変更を伴うことなく、ネットワーク・システムに接続される端末の設定を容易に行うことができるネットワーク・システムおよび端末設定方法を提供することにある。
さらに、この発明の目的は、ネットワーク・システムに接続される端末が使用するサーバ等の端末のIPアドレスの設定を容易に行うことができるネットワーク・システムおよび端末設定方法を提供することにある。各端末のIPアドレスはユーザが設定可能であって普遍的なものではないので、使用対象の端末に関する設定を容易に行うことができれば極めて有効である。
例えば、家庭内LANが無線LANによって構成されている環境で、無線LAN接続機能を有したモバイル(ポータブル)機器をいくつか利用する場合を考える。ここで、モバイル機器に、いわゆるリンクローカルアドレス(例えば、192.254.0.0/16)が予め割り当てられていると、1つのグループ(ネットワークアドレス)内で、使用のたびに自動的にIPアドレスが付与される。
上述した課題を解決するために、この発明は、IPネットワークに接続されたクライアント、クライアントと接続され、クライアントに対して所定のサービスを提供するアプリケーション・サーバ、およびアドレス解決サーバからなるネットワーク・システムであって、
クライアントは、使用するアプリケーションによって接続すべきアプリケーション・サーバMACアドレスが記録されている第1の記録手段を有し、
アドレス解決サーバは、アプリケーション・サーバ毎にMACアドレスおよびIPアドレスの対応関係を記録する第2の記録手段を有し、
クライアントおよびアプリケーション・サーバは、ARP要求をブロードキャストし、アドレス解決サーバは、ARP要求を受信することによって、クライアントおよびアプリケーション・サーバのそれぞれのMACアドレスおよびIPアドレスの対応関係を取得し、第2の記録手段に、取得した対応関係の情報を記録し、
クライアントは、アプリケーションが指示されると、第1の記録手段を参照して接続すべきアプリケーション・サーバのMACアドレスを求め、求められたアプリケーション・サーバのMACアドレスを含むRARP要求をネットワークにブロードキャストし、
アドレス解決サーバが、RARP要求を受信すると共に、第2の記録手段を用いてRARP要求に含まれているアプリケーション・サーバのMACアドレスに対応するIPアドレスを取得し、取得されたIPアドレスを含むRARP応答をクライアントに返信することを特徴とするネットワーク・システムである。
この発明は、IPネットワークに接続されたクライアント、クライアントと接続され、クライアントに対して所定のサービスを提供するアプリケーション・サーバ、およびアドレス解決サーバからなるネットワーク・システムの端末設定方法であって、
クライアントは、使用するアプリケーションによって接続すべきアプリケーション・サーバMACアドレスが記録されている第1の記録手段を有し、
アドレス解決サーバは、アプリケーション・サーバ毎にMACアドレスおよびIPアドレスの対応関係を記録する第2の記録手段を有し、
クライアントおよびアプリケーション・サーバは、ARP要求をブロードキャストするステップと、
アドレス解決サーバは、ARP要求を受信することによって、クライアントおよびアプリケーション・サーバのそれぞれのMACアドレスおよびIPアドレスの対応関係を取得し、第2の記録手段に、取得した対応関係の情報を記録するステップと、
クライアントは、アプリケーションが指示されると、第1の記録手段を参照して接続すべきアプリケーション・サーバのMACアドレスを求め、求められたアプリケーション・サーバのMACアドレスを含むRARP要求をネットワークにブロードキャストするステップと、
アドレス解決サーバが、RARP要求を受信すると共に、第2の記録手段を用いてRARP要求に含まれているアプリケーション・サーバのMACアドレスに対応するIPアドレスを取得し、取得されたIPアドレスを含むRARP応答をクライアントに返信するステップと
を含むことを特徴とするネットワーク・システムである。
この発明によれば、クライアントおよびアドレス解決サーバのソフトウエアを大幅に変更することなく、クライアントが使用するアプリケーション・サーバのIPアドレスの設定を容易に行うことができる。
この発明のネットワーク・システムのネットワーク構成および動作を、図1ないし図4を参照して説明する。図1は、この発明のネットワーク・システムのネットワーク構成の例を表す略線図である。このネットワーク・システムは、ネットワーク15と、これに接続されたクライアント1、アプリケーション(AP)サーバ2、APサーバ3、APサーバ4、およびRARPサーバ5から構成される。ネットワーク15は、この例では、接続された各端末がIPを使ってデータの送受信を行う、いわゆるIPネットワークである。
このようなネットワーク・システムは、例えば、クライアント1がワイヤレス液晶テレビジョンで、APサーバ2が、そのワイヤレス液晶テレビジョンに無線LAN(例えば、IEEE802.11b)を介してテレビジョン放送を配信し、あるいはインターネット接続を提供するベースステーションのようなものが考えられる。
ここで、RARPサーバ5は、アドレス解決サーバに対応する。また、後述するアプリケーションテーブル11は第1の記録手段に対応し、ARPテーブル12は第2の記録手段に対応する。
また、図1には、各端末のMACアドレスとIPアドレスとが示されている。例えば、クライアント1のMACアドレスはMAC−1、IPアドレスはIP−1である。実際のMACアドレスは、イーサネットの場合6バイトのバイナリデータであり、IPアドレスは、IPv4の場合4バイトのバイナリデータであるが、ここでは、MAC−1等の便宜的な表記を用いる。
各端末は、ディスクレス・ワークステーションのような特殊な端末ではなく、自身のIPアドレスを知っているものとする。これらの端末は、例えば、起動時や所定の時間間隔等で、ネットワークで自身のIPアドレスが使用されていないかをチェックするために、ARP要求パケットをブロードキャストする。クライアント1からのブロードキャストは、例えば、図1の点線矢印6で示されている。
図2Aには、クライアント1が送信する、ARP要求パケットを含んだイーサネットフレーム20の例が示されている。イーサネットフレーム20は、宛先MACアドレス、送信元MACアドレス、およびIPパケットを含み、ここでは、IPパケットがARP要求パケットに対応する。また、イーサネットフレーム20の各項目は、説明に必要なものを示しているに過ぎず、厳密なフレームのレイアウトを示すものではない。イーサネットフレーム20内には、(OSI(Open Systems Interconnection)参照モデルにおける)ネットワーク層で参照されるMACアドレスと、それより下位の層で参照されるMACアドレスとがあるが、ここでは、前者をMACアドレス2(宛先MACアドレス2、送信元MACアドレス2)、後者をMACアドレス1(宛先MACアドレス1、送信元MACアドレス1)と称することとする。
イーサネットフレーム20の宛先MACアドレス1には、このフレームをブロードキャストするために、全てのビットを1とした値(F〜F)が設定される。また、送信元MACアドレス1にはクライアント1のMACアドレスであるMAC−1が設定される。IPパケットのプロトコルタイプは、ARP要求を示すように設定される。ここでは簡略的な記載がされているが、実際は、例えば、プロトコルビットと動作ビットによってARP要求であることが示される。送信元MACアドレス2には、送信元MACアドレス1と同様、クライアント1のMACアドレスであるMAC−1が設定される。また、宛先IPアドレス、および送信元IPアドレスにはともにクライアント1のIPアドレスであるIP−1が設定される。
宛先IPアドレスをIP−1としているので、仮にIP−1のIPアドレスを有する端末がネットワーク上に存在すれば、その端末からクライアント1にARP応答パケットが返信されてくることになる。従って、クライアント1がブロードキャストしたARP要求パケットに対して、どの端末からも応答がなければ、IPアドレスに重複はなく、クライアント1は、IP−1というIPアドレスで問題なく起動することができる。
図2Bは、RARPサーバ5が有するARPテーブル12の内容を示したものである。RARPサーバは、背景技術の説明において説明したとおり、通常、事前に設定されたARPテーブルを備える。しかしながら、この発明においては、ARPサーバ5は、各端末が起動時等にブロードキャストする前述のARP要求パケットを受信することによって、各端末のIPアドレスとMACアドレスの値を取得し、ARPテーブル12にそれらの値を記録する。図2Aに示すイーサネットフレーム20から分かるように、送信元MACアドレス1、および送信元MACアドレス2には、例えば、MAC−1のような送信元のMACアドレスが含まれ、送信元IPアドレスには、例えば、IP−1のような送信元のIPアドレスが含まれており、RARPサーバ5は、ARP要求を受信した場合に、このMACアドレスとIPアドレスの対をARPテーブル12に追加する。
図2Bに示すARPテーブル12は、クライアント1、APサーバ2、およびAPサーバ3からそれぞれARP要求パケットを受信した結果生成されたものである。また、ARPテーブル12の各エントリーは、所定の時間が経過した場合にクリアすることが望ましい。それぞれの端末においてIPアドレスが変更される場合があるからである。
また、図1のクライアント1は、アプリケーションテーブル11を備えており、そのテーブルの一例が、図3Aに示されている。アプリケーションテーブル11は、各アプリケーションがどのAPサーバで実行されるかを示しており、また、そのサーバのMACアドレスも示している。ユーザが、例えば、クライアント1を操作してテレビジョン放送を当該クライアント1で再生させようと所定の指示をした場合、クライアント1は、その指示に応じて、テレビジョン放送を再生するためにアクセスすることが必要なTVアプリケーションのサーバにアクセスする。
この例では、テレビジョン放送の動画および音声を配信するTVアプリケーションは、APサーバ2で実行され、APサーバ2のMACアドレスはMAC−2であり、所定の記録媒体から提供される音楽を配信するミュージックアプリケーションは、APサーバ3で実行され、APサーバ3のMACアドレスはMAC−3である。また、所定の記録媒体から提供される動画または静止画を配信するイメージアプリケーションは、APサーバ4で実行され、APサーバ4のMACアドレスはMAC−4である。このように、この発明のクライアント1は、使用するサーバのMACアドレスを知っていることが前提になる。従って、出荷時等にセットで用意されるサーバであれば事前にこのようなアプリケーションテーブル11を作成しておくことが可能であるが、後で増設されるようなサーバは、アプリケーションテーブル11にMACアドレスを追加しなければならない。MACアドレスの追加については、例えば、可搬性記録媒体を介して提供されたり、クライアント1でMACアドレスを入力する機能を有するツールが提供される。
図3Aの例では、後述するAPサーバのIPアドレス取得方法によって得られたIPアドレスを、そのまま記憶している。この例では、APサーバ2のIPアドレスであるIP−2と、APサーバ3のIPアドレスであるIP−3が既に求められ、アプリケーションテーブル11に記憶されている。当該記憶によって、クライアント1が再びそのAPサーバにアクセスしようとするときに、IPアドレス取得処理を行わなくて済む。また、各APサーバのIPアドレスが変化することを考慮すると、このようにして求められたIPアドレスは、一定期間が経過したらクリアされるようにしておくこともできる。
次に、クライアント1がAPサーバにアクセスするために、そのIPアドレスを取得する処理について説明する。クライアント1は、最初に、クライアント1のアプリケーションが、APサーバにアクセス要求をした場合に、アプリケーションテーブル11を参照し、アクセス要求のあったAPサーバのIPアドレスが登録されているかどうかを判断する。
IPアドレスの登録がある場合はそれをそのまま用いてAPサーバにアクセスする。IPアドレスがない場合は、RARP要求パケットを用いてIPアドレスを求める。RARP要求パケットは、前述したように、本来は自身のIPアドレスを求めるために使用されるものであるが、この発明では、RARPの仕組みを利用して、他のAPサーバのIPアドレスを求める。
クライアント1は、図3Bに示すようなRARP要求パケットを含むイーサネットフレーム30を生成し、ブロードキャストする。ブロードキャストするのは、RARPサーバ5のIPアドレスが不明だからである。
イーサネットフレーム30の宛先MACアドレス1には、このフレームをブロードキャストするために、全てのビットを1とした値(F〜F)が設定される。また、送信元MACアドレス1にはクライアント1のMACアドレスであるMAC−1が設定される。IPパケットのプロトコルタイプは、RARP要求を示すように設定される。これについては、ここでも簡略的な記載がされている。
送信元MACアドレス2には、クライアント1のMACアドレスではなく、IPアドレスを求めるAPサーバのMACアドレスを指定する。ここでは、APサーバ4のMACアドレスであるMAC−4が設定されている。APサーバ4のMACアドレスは、アプリケーションテーブル11を参照することによって取得できる。送信元IPアドレスには、送信元であるクライアント1のIPアドレスであるIP−1が設定される。
RARPサーバ5がRARP要求パケットを受信すると、図3Cに示すRARP応答パケットを含むイーサネットフレーム40を生成し、クライアント1に、今度はユニキャストで送信する。イーサネットフレーム40の宛先MACアドレス1には、イーサネットフレーム30の送信元MACアドレス1、すなわちクライアント1のMACアドレスであるMAC−1がそのまま設定される。また、送信元MACアドレス1にはRARPサーバ5のMACアドレスであるMAC−5が設定される。IPパケットのプロトコルタイプは、RARP応答を示すように設定される。これについては、ここでも簡略的な記載がされている。
宛先MACアドレス2には、原則として、イーサネットフレーム30の送信元MACアドレス2、すなわちAPサーバ4のMACアドレスであるMAC−4がそのまま設定される。送信元MACアドレス2には、RARPサーバのMACアドレスであるMAC−5が指定される。
宛先IPアドレスに関しては、イーサネットフレーム30の送信元MACアドレス2に指定されたMAC−4に対応するIPアドレスが、図2Bに示すARPテーブル12を用いて検索され、その結果、IP−4が選択され、宛先IPアドレスに設定される。送信先IPアドレスには、RARPサーバ5のIPアドレスであるIP−5が設定される。
クライアント1は、RARPサーバ5から、このRARP応答パケットを受信することにより、APサーバ4のIPアドレスがIP−4であることを知ることができ、その後、APサーバ4との通信が、IPアドレス、IP−4を使用して行われる。ここで、クライアント1は、アプリケーションテーブル11に、MAC−4に対応するIPアドレスとして、IP−4を新たに記録する。
次に、図4のフローチャートを参照して、この発明の処理手順を説明する。図4は、APサーバ、RARPサーバ、クライアント毎の処理の流れを示しており、相互にやり取りされるメッセージは矢印で示されている。APサーバは、例えば、APサーバ2、APサーバ3、APサーバ4といったサーバである。最初に、APサーバのMACアドレスがRARPサーバ5に登録される処理について説明する。
ここで、RARPサーバ5は、最初から起動されているものとする。APサーバが起動されると、ステップS1において、RARPサーバ5に対して上述したようなARP要求のブロードキャストが行われる。RARPサーバ5は、ステップS2において、このARP要求を受信し、ステップS3において、APサーバのMACアドレスとIPアドレスをARPテーブル12に登録する。
これらの一連の処理によって、新たに起動されたAPサーバのMACアドレスおよびIPアドレスは、RARPサーバ5のARPテーブル12に記録される。必要に応じて、クライアント1が起動される場合にこのような、ARPテーブル12への記録を行っても良い。また、起動時のみでなく、所定の時間、あるいは所定の時間間隔等でこのような記録が行われても良い。
次に、クライアント1が、APサーバのIPアドレスを取得して、そのAPサーバに接続するまでの処理について説明する。
クライアント1が起動されてネットワーク・システムに接続した後、ユーザからの指示を受けると、その指示に対応するクライアント1のアプリケーションが、ステップS4で必要なAPサーバへのアクセスを要求する。クライアント1は、ここで、アプリケーションテーブル11を参照し、アクセス(接続)が必要なAPサーバのMACアドレスを求め、そのアプリケーションサービスアプリケーションのIPアドレスを取得するため、ステップS5においてRARP要求の含まれたフレームをブロードキャストする。なお、このアプリケーションテーブル11の参照によって、APサーバのIPアドレスが求められた場合は、以降のステップS5からS10の処理は不要となり、すぐにステップS11で、当該APサーバへの接続要求を行う。
RARPサーバ5は、ステップS7において、クライアント1からのRARP要求を受信すると、ステップS8でARPテーブル12を参照し、クライアント1が接続しようとするAPサーバのIPアドレスを求める。IPアドレスが得られたら、ステップS9において、このIPアドレスをIPヘッダにセットし、クライアント1に対してRARP応答をユニキャストにて送信する。
クライアント1からのRARP要求はブロードキャストされるため、APサーバ等にも送信され、ステップS6でこれを受信することになるが、ここでは、APサーバ等はRARPサーバとして設定されていないため、後続する処理を行わず、受信したパケットは破棄する。
クライアント1が、ステップS10において、RARPサーバ5からのRARP応答を受信することによって、接続しようとするAPサーバのIPアドレスが判明する。そこで、クライアント1は、ステップS11で、APサーバのMACアドレスおよびIPアドレス、その他必要な事項を指定して、APサーバへの接続要求を行う。
APサーバは、ステップS12において、クライアント1からの接続要求を受信し、その内容をチェックした後、所定の条件を満足すれば、ステップS13において、接続許可応答をクライアント1に送信する。
クライアント1は、ステップS14において、APサーバからの接続許可を受信すると、所定の手順によって、APサーバへの接続を行い、所定のデータ送受信を行う。
このように、RARPサーバ5は、RARP応答パケットを、ARPテーブル12の内容に従って生成し、送信する。ARPテーブル12の内容は、各端末の起動時等のARP要求を元に作られているので、端末のIPアドレスが変化しても、その変化がARPテーブル12に反映される。
一方、クライアント1は、従来のRARPの仕組みを用いて、すなわち、一般的なRARP要求をブロードキャストすることによって、アクセスするAPサーバのIPアドレスを取得することができるので、クライアント1およびRARPサーバ5に関してソフトウエアの大幅な変更を加える必要がない。
これまで、この発明をIPv4を前提として説明してきたが、他のバージョンのIPについても適用することが可能である。また、上記の例では、APサーバがアプリケーション毎に複数設定されているが、1つのAPサーバにまとめて構成することもできる。さらに、こうしてまとめられたAPサーバとRARPサーバとを1つのサーバで実現しても良い。
この発明の一実施形態にかかるネットワーク・システムのネットワーク構成を表す略線図である。 クライアント1が送信するRARP要求を含むフレームの例、およびRARPサーバ5のARPテーブル12の例を示す略線図である。 クライアント1のアプリケーションテーブル11の例、およびRARP要求、RARP応答を含むフレームの例を表す略線図である。 APサーバ、RARPサーバ、およびクライアントの処理をそれぞれ示すフローチャートである。 従来のネットワーク・システムのネットワーク構成を表す略線図である。 ARP要求、ARP応答を含むフレーム等の内容を示す略線図である。 ARPテーブルの内容を表す略線図である。 RARP要求、RARP応答を含むフレームの内容を示す略線図である。
符号の説明
1・・・クライアント、2,3,4・・・APサーバ、5・・・RARPサーバ、11・・・アプリケーションテーブル、12・・・ARPテーブル

Claims (8)

  1. IPネットワークに接続されたクライアント、前記クライアントと接続され、前記クライアントに対して所定のサービスを提供するアプリケーション・サーバ、およびアドレス解決サーバからなるネットワーク・システムであって、
    前記クライアントは、使用するアプリケーションによって接続すべき前記アプリケーション・サーバMACアドレスが記録されている第1の記録手段を有し、
    前記アドレス解決サーバは、前記アプリケーション・サーバ毎にMACアドレスおよびIPアドレスの対応関係を記録する第2の記録手段を有し、
    前記クライアントおよび前記アプリケーション・サーバは、ARP要求をブロードキャストし、前記アドレス解決サーバは、前記ARP要求を受信することによって、前記クライアントおよび前記アプリケーション・サーバのそれぞれのMACアドレスおよびIPアドレスの対応関係を取得し、前記第2の記録手段に、前記取得した前記対応関係の情報を記録し、
    前記クライアントは、前記アプリケーションが指示されると、前記第1の記録手段を参照して接続すべき前記アプリケーション・サーバのMACアドレスを求め、前記求められた前記アプリケーション・サーバのMACアドレスを含むRARP要求を前記ネットワークにブロードキャストし、
    前記アドレス解決サーバが、前記RARP要求を受信すると共に、前記第2の記録手段を用いて前記RARP要求に含まれている前記アプリケーション・サーバのMACアドレスに対応するIPアドレスを取得し、前記取得されたIPアドレスを含むRARP応答を前記クライアントに返信することを特徴とするネットワーク・システム。
  2. 請求項に記載のネットワーク・システムにおいて、
    前記クライアントは、IPヘッダの送信元MACアドレスに前記アプリケーション・サーバのMACアドレスを指定して前記RARP要求を生成することを特徴とするネットワーク・システム。
  3. 請求項1に記載のネットワーク・システムにおいて、
    前記ネットワークが有線LANまたは無線LANであることを特徴とするネットワーク・システム。
  4. 請求項に記載のネットワーク・システムにおいて、
    前記アプリケーション・サーバと前記アドレス解決サーバが、1つのサーバで構成されることを特徴とするネットワーク・システム。
  5. IPネットワークに接続されたクライアント、前記クライアントと接続され、前記クライアントに対して所定のサービスを提供するアプリケーション・サーバ、およびアドレス解決サーバからなるネットワーク・システムの端末設定方法であって、
    前記クライアントは、使用するアプリケーションによって接続すべき前記アプリケーション・サーバMACアドレスが記録されている第1の記録手段を有し、
    前記アドレス解決サーバは、前記アプリケーション・サーバ毎にMACアドレスおよびIPアドレスの対応関係を記録する第2の記録手段を有し、
    前記クライアントおよび前記アプリケーション・サーバは、ARP要求をブロードキャストするステップと、
    前記アドレス解決サーバは、前記ARP要求を受信することによって、前記クライアントおよび前記アプリケーション・サーバのそれぞれのMACアドレスおよびIPアドレスの対応関係を取得し、前記第2の記録手段に、前記取得した前記対応関係の情報を記録するステップと、
    前記クライアントは、前記アプリケーションが指示されると、前記第1の記録手段を参照して接続すべき前記アプリケーション・サーバのMACアドレスを求め、前記求められた前記アプリケーション・サーバのMACアドレスを含むRARP要求を前記ネットワークにブロードキャストするステップと、
    前記アドレス解決サーバが、前記RARP要求を受信すると共に、前記第2の記録手段を用いて前記RARP要求に含まれている前記アプリケーション・サーバのMACアドレスに対応するIPアドレスを取得し、前記取得されたIPアドレスを含むRARP応答を前記クライアントに返信するステップと
    を含むことを特徴とする端末設定方法。
  6. 請求項に記載の端末設定方法において、
    前記クライアントにより、
    IPヘッダの送信元MACアドレスに前記アプリケーション・サーバのMACアドレスを指定して前記RARP要求を生成するステップを有することを特徴とする端末設定方法。
  7. 請求項に記載の端末設定方法において、
    前記ネットワークが有線LANまたは無線LANであることを特徴とする端末設定方法。
  8. 請求項に記載の端末設定方法において、
    前記アプリケーション・サーバと前記アドレス解決サーバが、1つのサーバで構成されることを特徴とする端末設定方法。
JP2004012756A 2004-01-21 2004-01-21 ネットワーク・システムおよび端末設定方法 Expired - Fee Related JP3969395B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004012756A JP3969395B2 (ja) 2004-01-21 2004-01-21 ネットワーク・システムおよび端末設定方法
US11/039,481 US20050180439A1 (en) 2004-01-21 2005-01-20 Network system, terminal setting method, address resolving server, and client terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004012756A JP3969395B2 (ja) 2004-01-21 2004-01-21 ネットワーク・システムおよび端末設定方法

Publications (2)

Publication Number Publication Date
JP2005210265A JP2005210265A (ja) 2005-08-04
JP3969395B2 true JP3969395B2 (ja) 2007-09-05

Family

ID=34835799

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004012756A Expired - Fee Related JP3969395B2 (ja) 2004-01-21 2004-01-21 ネットワーク・システムおよび端末設定方法

Country Status (2)

Country Link
US (1) US20050180439A1 (ja)
JP (1) JP3969395B2 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4670670B2 (ja) * 2005-03-23 2011-04-13 パナソニック株式会社 構内交換機システム
US7715409B2 (en) * 2005-03-25 2010-05-11 Cisco Technology, Inc. Method and system for data link layer address classification
KR101124748B1 (ko) * 2005-05-27 2012-03-23 엘지전자 주식회사 네트워크 설정 장치 및 방법
US8576846B2 (en) 2005-10-05 2013-11-05 Qualcomm Incorporated Peer-to-peer communication in ad hoc wireless network
EP1989827B3 (en) 2006-03-02 2015-11-11 Nokia Corporation Supporting an access to a destination network via a wireless access network
JP2007293664A (ja) * 2006-04-26 2007-11-08 Murata Mach Ltd 情報処理装置、画像形成装置、プログラムおよび記録媒体
DE602006007151D1 (de) * 2006-10-24 2009-07-16 Abb Research Ltd Simulation von Feldgeräten in einem computerbasierten Steuersystem
US7840655B2 (en) * 2007-11-14 2010-11-23 International Business Machines Corporation Address resolution protocol change enabling load-balancing for TCP-DCR implementations
JP4621963B2 (ja) * 2007-11-29 2011-02-02 Necインフロンティア株式会社 情報処理システム、情報処理装置および情報処理方法
CN102075591A (zh) * 2010-12-21 2011-05-25 华为技术有限公司 获取介质访问控制地址的方法、装置和***
US8923133B2 (en) * 2010-12-27 2014-12-30 Symbol Technologies, Inc. Detection of unauthorized changes to an address resolution protocol cache in a communication network
JP6344169B2 (ja) * 2014-09-12 2018-06-20 パナソニックIpマネジメント株式会社 制御装置、プログラム
CN105828174B (zh) * 2015-01-05 2019-11-05 中兴通讯股份有限公司 一种分享媒体内容的方法和装置
CN113746945B (zh) * 2020-05-30 2023-09-12 华为技术有限公司 反向地址解析方法及电子设备

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5526489A (en) * 1993-03-19 1996-06-11 3Com Corporation System for reverse address resolution for remote network device independent of its physical address
US6061739A (en) * 1997-11-26 2000-05-09 International Business Machines Corp. Network address assignment using physical address resolution protocols
US6697360B1 (en) * 1998-09-02 2004-02-24 Cisco Technology, Inc. Method and apparatus for auto-configuring layer three intermediate computer network devices
JP2001111628A (ja) * 1999-10-08 2001-04-20 Matsushita Graphic Communication Systems Inc 画像送信装置、画像受信装置およびそれらの方法
US6795403B1 (en) * 2000-03-31 2004-09-21 Cisco Technology, Inc. Automatic discovery of switch devices in a network
US6854072B1 (en) * 2000-10-17 2005-02-08 Continuous Computing Corporation High availability file server for providing transparent access to all data before and after component failover
JP3502048B2 (ja) * 2001-02-02 2004-03-02 パナソニック コミュニケーションズ株式会社 画情報送信システム、スキャナ装置およびユーザー端末装置、並びに画情報送信方法
US7155497B2 (en) * 2001-09-27 2006-12-26 Hewlett-Packard Development Company, L.P. Configuring a network parameter to a device
JP3736451B2 (ja) * 2001-12-18 2006-01-18 ブラザー工業株式会社 アドレス推定システム、ネットワークデバイス、アドレス推定方法およびアドレス推定プログラム
JP2003224576A (ja) * 2002-01-30 2003-08-08 Nec Corp Lan型インタネット・アクセス網及びそれに用いる加入者線収容方法
JP4032816B2 (ja) * 2002-05-08 2008-01-16 株式会社日立製作所 ストレージネットワークトポロジ管理システム
US7058796B2 (en) * 2002-05-20 2006-06-06 Airdefense, Inc. Method and system for actively defending a wireless LAN against attacks
JPWO2004051935A1 (ja) * 2002-12-05 2006-04-06 アライドテレシスホールディングス株式会社 ユーザ特定システム、ユーザ特定装置、ユーザ特定方法、アドレス変換装置、及びプログラム
US7188245B2 (en) * 2002-12-09 2007-03-06 Kabushiki Kaisha Toshiba Contents transmission/reception scheme with function for limiting recipients
US7523485B1 (en) * 2003-05-21 2009-04-21 Foundry Networks, Inc. System and method for source IP anti-spoofing security

Also Published As

Publication number Publication date
US20050180439A1 (en) 2005-08-18
JP2005210265A (ja) 2005-08-04

Similar Documents

Publication Publication Date Title
US20050180439A1 (en) Network system, terminal setting method, address resolving server, and client terminal
US7729292B2 (en) Method and apparatus for detecting a router that improperly responds to ARP requests
US7339895B2 (en) Gateway device and control method for communication with IP and IPV6 protocols
JP3876732B2 (ja) ゲートウェイ装置、ゲートウェイ装置のアドレス管理方法及びゲートウェイ機能を有するav機器
US7266090B2 (en) Address autoconfiguration method for home network
KR100796865B1 (ko) 이동 통신 단말기와 이를 이용한 네트웍 접속 시스템 및그 방법
US8001223B2 (en) Automatic switching network points based on configuration profiles
US20070091908A1 (en) Communication device and communication control method using efficient echonet address determination scheme
US8631087B2 (en) Information processing server, remote control system, and remote control method using a tunnel to determine a service on another network and executing the service without using the tunnel
US20050018677A1 (en) Method and system for generating IP addresses of access terminals and transmitting messages for generation of IP addresses in an IP system
US20060050673A1 (en) Method and apparatus for acquiring IP address in DHCP environment
US20090245266A1 (en) Universal plug and play device and method of resolving network address conflict by considering remote access
US7630311B2 (en) Location management server and ethernet-based wireless LAN distribution system having local management server, and embodiment method thereof
WO2009090707A1 (ja) 通信端末装置及び通信機器接続制御方法
WO2016202056A1 (zh) 一种家庭网络服务共享的方法及装置
WO2013185731A2 (zh) 一种自动管理IPv6地址冲突的方法及***
JP2003204345A (ja) 通信システム、パケット中継装置、パケット中継方法、及び中継プログラム
JP3806094B2 (ja) ルータ装置、ネットワークアドレス管理システム、ネットワークアドレス管理方法及びネットワークアドレス管理プログラム
US8438390B2 (en) Method and system for using neighbor discovery unspecified solicitation to obtain link local address
CN1875573B (zh) 提供能够在不同类型的网络之间进行数据通信的隧道服务的方法、节点和服务器
JP4019666B2 (ja) ゲートウェイ装置および情報機器
US20120079296A1 (en) Communication device management apparatus, user device, and service device
JP3960321B2 (ja) 電子機器
KR20050026752A (ko) 멀티미디어 컨텐츠 멀티캐스팅 시스템
JP4434062B2 (ja) Webサーバ搭載機器への自動アクセス方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20061204

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061212

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070213

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070515

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070528

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100615

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees