ICPを使ったネットワークプログラミング

インターネットの普及とともにスポットを浴びているのが、インターネット技術を使った社内システム、すなわちイントラネットの構築だ。イントラネットと言うと、とかくWWWシステムを使うことばかりが取りざたされているが、実際にはそれだけではない。ここでは、Visual BasicとMicrosoft ActiveX Internet コントロールを使い、イントラネットの可能性を探ってみよう。

酒井 法雄

• ネットワークでコンピュータは変わる

  昨年は、アポロ13号を扱った映画が脚光を浴びた。最近の映画はCGを巧みに使って いるが、この映画ではいっそう磨きがかかったものとなっている。サターン5型ロ ケットの発射シーンの製作風景については、NHKのTV番組でも紹介されていたので 、感心した方も多かったのではないだろうか。アポロ計画はコンピュータを使った 計算と制御により、99.99...%と9がいくつか並ぶという成功率であると当時報道さ れたものであった。コンピュータとか電子計算機というものに縁遠かった当時の一 般人、まして私などは小学生であったから、これはとてつもないものなのだろうと 思った。
  しかし、何年か前にどこかで聞きかじった話だと、当時NASAで使われたコンピュ ータの能力は、PC-9801VMだかVX程度のものだったという。それから数年を経て、 私たちが使っているパーソナルコンピュータはさらに10倍以上もの高速化、大容量 化を果たしている。だいたいが、数万円でヨドバシカメラで売っているゲーム機か らして、数年前のワークステーション以上の処理能力を持っているというのだから 驚きだ。
  こういった単体としてのコンピュータの進化も驚きであったが、近ごろのインター ネットブームは、さらなる驚きである。インターネットは、1960年代後半にスター トしている。そもそも米国国防総省の研究プロジェクトとして開始されたものであ るが、その目的は複数のコンピュータを接続して分散処理をさせる実験であったと いう。こうした研究プロジェクトから数年前の商用化を経て、いまや一大ブームで ある。こうしたブームとなりえたのは、インターネットという研究実験時代からの インフラがあったこともともかく、パソコンのOSが標準でネットワークをサポート するようになってきたからだ。
  もちろん、標準でなかった頃からパソコンでもオプションとしてネットワークを使 うことはできた。ちまたでは、NetWareサーバーを導入してプリンタの共有やファ イルの共有といったことがなされてきたし、その後はRDBMSサーバーなども利用さ れてきた。これらは、プリンタやファイル、データなどを集中して管理し、それら を複数のパソコンから共有しようという発想だった。
  一方、インターネットとともに進化してきたUNIXでは、電子メイルやニュースとい ったものを扱うプロトコルが作られ、さらにRPCを使った分散処理なども画策され てきた。そういった中で、今日のインターネットブームの起爆剤となったのか、 WWW(World Wide Web)である。このシステムは、テキストやマルチメディアデータ などが混在したような正規化しにくいデータを扱うデータベースである。しかも、 ネットワークの特質を活かして、データを分散しておきながら、ハイパーリンクを 使って自在に検索ができるという画期的なものであった。このような分散したデー タがクモの巣上に世界中に張り巡らされることから、WWWという名前になっている という。
  とかく、インターネットといえばWWW、要はブラウザであちこちのホームページを 見ることだというように捉えられがちだが、実際には世界規模のデータベースシス テムがWWWであり、それらを接続するためのインフラがインターネットであるのだ 。そして、これらのシステムを支える技術こそ、インターネットの実験時代から進 化してきたUNIXなのである。
  しかし、すでにUNIXでなければインターネットに繋がらないという時代ではない。 あなたのパソコンは、もはやあなただけのものではなくなる。世界中に広がるイン ターネットの一部、世界規模の分散コンピューティングシステムの一部になりえる のだ。

• クライアント/サーバーシステムからイントラネットへ

  こうしたネットワーク技術の進化の過程を考えると、ネットワークという技術を使 いながらも、それらの位置づけが変化してきたことが分かる。しかし、そうしたご 大層な話がある一方で、身近にある仕事あるいは処理を楽にするための仕組みとし て考えると、仕事が変わるわけではなく、方法が変わるにすぎない。
  たとえば、昨年くらいまでは合い言葉のように使われてきた「ダウンサイジング」 とか「クライアント/サーバーシステム」(C/S)、「グループウェア」といった言葉 がある。これらの言葉は、従来ミニコン以上の高価なコンピュータを使ってきた処 理を、安価で高性能なパソコンにやらせようというものだ。同時に、端末対ホスト というスタイルから、単独での処理能力を持ったワークステーションをクライアン トとしての、C/S型システムにして、トータルにパワーのあるシステムにしようと いうことであった。パソコンでも、C/S型として使うなら十分に処理能力があると いうことである。
  C/S型システムで処理できる内容としては、大きく分けてOracle7 ServerやSQL ServerといったRDBMSと、Lotus Notesを筆頭としたグループウェアに分けることが できる。これらは、C/Sの普及のために、低価格になってきた。しかし、実際には C/S環境を構築するためのツールやミドルウェアは発展途上であり、やっと昨年後 半になって整備されてきたというのが実情だった。
  そこへきて、インターネットのブームである。インターネットの技術はインターネ ット以外にも応用できるというので、にわかに注目されたのがイントラネットとい う言葉である。イントラネットと言えば、とかくWWWを使ったシステムを考えがち であるが、もともとはそういうことではない。インターネットでの様々な技術を社 内システムとして使うというものだ。もっとも、単なるLANではなくWANとなるこ ともあるし、インターネットのインフラを同時に利用することもできる。さらには 、同じシステムでも、社内向けと社外向けに公開するものを変えることで、インタ ーネットでの情報発信や様々なサービスにも活用することができるということで、 一石二鳥というわけだ。
  インターネットの技術というのは、主としてプロトコルをベースとしたものとし て考えることができる。しかし、実際問題としてC/Sに対してアドバンテージを持 つのは、使いやすさと柔軟性を持ち合わせたWWWが筆頭になってしまう。そんなわ けで、とかく「イントラネット=社内WWW」みたいな図式になってしまうのも事実 である。

• イントラネットでできること

  では、イントラネットではどんなことができるのであろうか。WWWのシステムを見 ても、単なる情報発信だけではなく、今や多彩なサービスが行われるようになって いる。したがって、WWWだけで考えても、アイデアと技術力次第では、かなりいろ いろなことができるだろう。さらに、JavaやJava Script、MicrosoftのActiveX技術な どが普及してくれば、単なるHTTPではなく他のプロトコルも混在したシステム、あ るいはまったく新しいプロトコルがイントラネット向きに作られるということも考 えられるだろう。
  将来のことはともかく、従来C/Sで行われてきた業務は、向き不向き、あるいは使 い勝手のよさ悪さがあるにしろ、ほとんどのことがWWWを中心としたイントラネッ トで実現可能である。これには、次のようなものが考えられる。

  スケジュール管理
  

  会議室予約
  

  営業情報の交換
  

  顧客情報システム
  

  商品管理システム
  

  受注発注システム
  

  製品情報システム
  

  社内情報掲示板
  

  ニュース
  

  電子メイル
  

  これらのうち、ニュースやメイルについては、インターネットと共通のプロトコル を使えば、インターネットのシステムと融合させることができる。他のシステムに ついては、WWWを使うこともできるし、Lotus Notesのように独自のシステムを構築 することもできるだろう。しかし、一部のデータは外部にも公開しようということ であれば、必然的にWWWが使われることになりだろう。
  WWWを使うメリットは、構築や管理がたやすいということにある。C/S型ではある 程度のパワーを持つクライアントマシン上で動作する、それなりの処理を行うこと のできるプログラムを作る必要があった。そういったプログラムは、サーバー側と 通信をするためのプロトコルが必要になる。RDBMSであれば、さらにミドルウェア が必要になり、これが各社独自のものであったためMicrosoftはODBCを提案したり もしていた。これらのミドルウェアのライセンス料金や、クライアントプログラム の開発に必要な技術、さらには各社ばらばらな開発ツールの使いこなしなど、ハー ドルは多くかつ高かったと言わざるを得ない。もちろん、サーバー側の管理も一筋 縄ではいかないのは言うまでもない。
  一方、WWWではサーバー側にコンテンツを作ってしまえば、市販の、あるいはフリ ーのブラウザで閲覧できるばかりか、検索や入力もできてしまう。もっとも、これ だけでは自由度が低い。しかし、JavaやJava Script、ActiveXコントロールやVB Scriptなどを使えば、サーバーからクライアントサイドにプログラムをダウンロード して実行させるといったこともできるのだから、今や技術力さえあれば、C/Sに負 けないシステムを構築することもできる。要は、すべてはサーバー側で済んでしま うというところがメリットなのだ。
  もっとも、端で言うほどカンタンではないのも事実である。サーバーOSの選択、 WWWサーバーの選択、システム設計などは、まだまだ日進月歩であり、最良の選択 は難しい。特に、RDBMSとの連携部分やCGIに代わるインプロセスタイプの実行環 境などは、統一が取れていない。さらに、ノウハウが確立されていない部分も少な くないから、アイデアや技術力も要求される。さらに、JavaだのActiveXだの話がだ んだん複雑になってきている。もちろん、運用上の管理なども、そうカンタンでは ないし、セキュリティなどにも気を使わないといけない。そういう意味では、中途 半端に手を出すと痛い目に合うことも考えられる。 このように考えてくると、すべてをWWWで実現しようというのには無理があるよう に思えてくる。よく考えてみれば、WWWのベースとなっているHTTPは非常に単純な プロトコルであり、それゆえに普及したというところがある。ここへ、Javaだ ActiveXだDCOMだとかいう話がどんどん入ってくると、本来の簡潔さがなくなって しまう。特にDCOMのようにHTTPの影で別のプロトコルが同時に動くなどという仕 組みを作るくらいだったら、もっといいプロトコルを普及させることでも考えてく れと言いたくなる。
  そんなわけで、WWWを中心としたイントラネットは、確かに従来のC/Sに比べると 、コストも開発期間も押さえられるが、それには相応の技術力やセンスも必要にな る。また、できたモノもC/S用に作成されたプログラムほど自由度はないのが現状 である。

• WWW以外のプロトコル

  では、C/S用に作成されたプログラムをしのぐほどの自由度のあるものをイントラ ネットで作ることはできないのだろうか。もちろん、そんなことはない。ただし、 WWWを使った方がスマートなものは、そのままWWWを使った方がいい。
  自由度を高くするには、どうすればいいだろうか? 答えはカンタンだ。WWWのしく みに縛られない、すなわちHTTPを使わないということにすればよい。イントラネッ トとかインターネットと言ってWWWしか思い付かないようだと、WWWを使わないな どといった瞬間に、それではイントラネットではないということになりそうだ。し かし、そんなことはない。現に、メイルやニュースなどといったプロトコルはHTTP とはまったく関係ないではないか。
  そこで、まずはプロトコルというものについて、確認しておこう。プロトコルとは 、コンピュータ同志が会話をするための取り決めである。人間であれば、プロトコ ルを特に決めておかなくても、その場で合理的な判断をして会話をすることができ るように思える。しかし、その裏には常識とかマナーとかがあるからできるのであ る。同じ人間であっても、ときどきプロトコルが合わなくて会話できないタイプの ヒトがいることもある。コンピュータの場合にも、こうした常識とかマナーを作っ ておかなくてはならない。
  実際には、プロトコルは階層化されて表現される。人間の会話で考えてみれば、口 があって耳がないと会話はできない。さらに、共通の言語が必要になる。その場に ヒトがたくさんいれば、特定のヒトを識別できないといけない。ここまでできれば 、誰かが誰か、あるいは複数のヒトに対して会話を開始することができる。そこか ら上の会話は、ずっと楽になるような気がするが、ある程度の共通の認識がなけれ ば成立しない。たとえば、共通の流行語などである。コギャルに「チョベリバ」(超 Very Badの略らしい。どうでもいいが、チョーはやめろ!)とか言われても、何だか 分からないのがふつーの日本人というものだ。
  こういった順番に(少々無理があったような気もするが)、プロトコルも階層化でき るというわけだ。
  

  
  アプリケーション層	HTTP, FTP, SMTPなど		話題
  プレゼンテーション層	圧縮やビットストリーム変換	流行語
  セッション層		セッションの確立と継続		相手との会話の開始
  トランスポート層	TCP, UDPなど			自分と相手の特定
  ネットワーク層		IP				自分と相手の定義
  データリンク層		Ehernet, PPP, Slip, FDDIなど	言語
  物理層			同軸ケーブル、より対線など	口や耳
  

  こういったわけで、プロトコルというとTCP/IPだとかHTTPだとかFTPだとか言われる ものの、実際にはまったく階層が異なるものもあるし、組み合わせを指すものもあ るのだ。
  HTTPは、表からもわかるように一番上のアプリケーション層にある。すなわち、確 実に相手と接続することができ、確実にデータを転送できる(実際には確実ではなく 、できるかぎりがんばって転送するというのがTCP/IPだが)という前提で、会話のこ とだけを考えたものだ。FTPやメイルのSMTP、POPなどもこの階層である。つまり、 この階層でできることはガチガチに決まっていると考えてよい。関西方面で「もう かりまっか」と聞かれたら「ボチボチでんな」、青森で「どさ」と聞かれたら「ゆ さ」(「どこにいくのですか?」「風呂屋にいってきます」の意)、と応えないといけ ないようなものである(これもちょっと違うような気もする)。したがって、この層 で決まっているプロトコルでは、プログラムを作るにしても、せいぜいユーザーイ ンターフェイスとか付加機能とかに凝る程度のことで、新しいコトはできないと考 えてよい。
  面白いのは、面倒なことはだいたいこなしてくれたIPより上の層のプロトコルを利 用することである。これには、TCPとUDPがある。 TCPは、特定の相手とセッションを張って会話するためのものであり、UDPはある程 度不特定の相手にデータを送るものである。したがって、TCPは一対一の通信であ り、UDPはラジオやテレビの放送のようなものである。用途によってこれらを使い 分ければよい。
  TCPやUDPをカンタンに使える仕組みさえあれば、その上で勝手な流行語を使おうが 、ヲタクな話をしようが、相互に分かり合えればなんでもありだ。つまり、電話で どんな会話をしようが、モデムを使おうが、FAXに使おうが自由というわけだ。自 分で決めた勝手なプロトコルを使うことができるのだ。どんなな勝手なものであっ ても、社内でしか使わないのならば、ヨソに通じなくても問題はない。 ただし、UDPは放送であるから、不特定多数に迷惑をかけるようなことは放送法で 禁止されていることを思い出していただきたい。いたずらにネットワークのトラフ ィックを増やすようなことはしないようにしよう。ついでに、「あたしのブラウザ ? ネットなんとかっていうんだけど、マウス? だけでネットサーフィン? できるの 。チョベリグよっ」とかいちいち尻上がりに言うのも、少なくとも放送ではやめて ほしいものだ。最近ではアナウンサーがインタビューでこれをやっていたので、チ ョームカついた。

• ICPとは

  インターネットとかイントラネットというと、WWWだからサーバーの面倒見られな いと何にも技術的に面白いことはできないから、そろそろVisual Basicからも足を洗 って、CGIとかJavaでもやるかなどとお考えだったアナタにも、ついにチャンスが きたのだ。そう、勝手なプロトコルを作ればWWWなど無視して、適当な開発ツール でも楽しいことができるのである。もちろん、Visual BasicでもOKだ。
  「しかし、TCP/IPを使うためにはWinSockのAPI使わないといけないんだよなあ」と 尻込みする必要はもうない。何と、Microsoftからインターネット用のActiveXカスタ ムコントロールパック、略してICPが提供されたのだ。原稿執筆時にはβリリースで あるが、表のようなプロトコルをサポートしている。
  

  コントロール	サポートするプロトコル
  
  FTP		File Transport Protocol (FTP)
  HTML		HyperText Transfer Protocol (HTTP)
  HTTP		HTTP 
  NNTP		Network News Transport Protocol (NNTP)
  POP		Post Office Protocol, version 3 (POP3)
  SMTP		Simple Mail Transport Protocol (SMTP)
  WinSock TCP	Transmission Control Protocol/Internet Protocol (TCP/IP)
  WinSock UDP	UDP/IP
  

  次に、各コントロールの概要を述べよう。
  • WinSock TCP ActiveX コントロール
    クライアントおよびサーバー用があり、相手を指定する、すなわちTCP/IPを使った 通信を実現する。実行時には非表示であり、双方向のデータ交換が可能だ。これさ えあれば何でもありだ。
    
  • WinSock UDP ActiveXコントロール
    クライアントおよびサーバー用があり、相手を指定しない、すなわちUDPでのブ ロードキャストを使った通信ができる。実行時には非表示であり、双方向のデータ 交換が可能だ。これさえあれば本当に何でもありだ。
    
  • FTP ActiveX コントロール
    FTPクライアントのコントロール。ファイル転送を実現する。実行時は非表示。
    
  • HTTP ActiveX コントロール
    HTTPクライアントのコントロールである。つまり、HTMLドキュメントを直接取得 できるものだ。MIMEの情報も得られる。
    
  • HTML ActiveX コントロール
    ここまでくると病気だが、HTMLデータの分析とレイアウトをしてしまうコントロ ールだ。つまり、これだけでもうブラウザである。主な特徴は次の通り。
    スクロールビュー
    インライングラフィック： GIF, JPEG, BMP, XBM
    HTML バージョン 2.X ＋ NetScape 2.0 ・ Explorer 2.0 の主な拡張仕様
    埋込み HTTP ・ ファイル URLs…
    
  • NNTP ActiveX コントロール
    ニュースサーバへの接続、ニュースグループ・記事のリスト表示、記事の取得・ 投稿ができる。
    
  • SMTP ActiveX コントロール
    SMTPメールサーバーへのアクセスをし、インターネットメールの投函ができる。
    
  • POP ActiveX コントロール
    POP3プロトコルによるメールサーバーへのアクセスをし、メールサーバーからのイ ンターネットメールの取得が可能になる。
    

  これだけの内容があって、タダである。誰でもインターネットのMicrosoftのサイト にアクセスできれば、HTTPでダウンロードすることができる。製品版でどうなるの か分からないが、限りなくタダに近いのは間違いない。現状ではいくつかバグが明 らかにされているが、それも製品版では修正されることだろう。
  これらのコントロールがスゴいのは、UNIXのサーバーさえあればこのへんのプロト コルを使ったツールを即使えるということだ。しかも、本当に即使えそうなサンプ ルプログラムまで別途用意されているのである。メイルやニュースリーダーに始ま って、WWWブラウザ、さらにはMCI APIを派手に使った電話まであるという凝りよ うだ。
  この製品でちょっと不思議なのは、Windows NTのBackOfficeファミリーの中で、イ ンターネットに対応するために重要な意味を持つExchangeサーバーなどがまったく 必要ないことだ。そのへんで1800円のFreeBSDのCD-ROMを買ってきて、余ってい る486マシンにインストールしてしまえば、UNIXサーバーのでき上がりで、Internet Readyである。Windows 95やWindows NTが動くマシンにICPをインストールし、てき とーにプログラムを作れば、メイルもニュースも使うことができてしまう。うーん 、素晴らしい。
  しかし、それではさっぱり面白くない。もちろん、SMTPとPOP3を使った使い勝手の よいメイルアプリケーションを作るのもいいが、それはあまりにも芸がない。さら に芸がないのはHTMLなんかを使ってしまうことだ。
  すでに前の節で述べたように、面白いのは勝手なアプリケーション層のプロトコル を作って、勝手な通信をしてしまうことだ。となれば、必然的にTCPとかUDPを使う ということになる。
  そこで、ここではTCPとUDPのActiveXコントロールの基本的な使い方と、TCPを使っ たチャットプログラム、もとい、リアルタイム電子会議システム(らしきもの)を作 ってみることにしよう。

• TCPコントロールの使用法

  TCPコントロールは、トランスポート層に位置するTCPプロトコルを使い、いわゆる TCP/IP接続して特定の相手と通信をするためのコントロールである。したがって、 接続が確立したあとは、何をやってもいい。元気があるなら、WWWブラウザを作っ たって、WWWサーバーを作ったっていい。
  TCPコントロールには、次のプロパティ、メソッド、イベントがある。
  

  
  ★ プロパティ
   BytesReceived		バッファに溜まっている受信したデータのバイト数
   LocalHostName		自分のマシンの名前を得る
   LocalIP			自分のマシンのIPアドレスを得る
   LocalPort		ローカルマシンのポート
   RemoteHost		リモートマシンの名前あるいはアドレス
   RemoteHostIP		相手マシンのIPアドレス
   RemotePort		リモートマシンのポート
   SocketHandle		ソケットのハンドル
   State			接続状態
   
   Constant		Value	Description
   sckClosed		0	Default. Closed
   sckOpen		1	Open
   sckListening		2	Listening
   sckConnectionPending 	3	Connection pending
   sckResolvingHost 	4	Resolving host
   sckHostResolved	5	Host resolved
   sckConnecting 		6	Connecting
   sckConnected 		7	Connected
   sckClosing 		8	Peer is closing the connection
   sckError 		9	Error
   
   
  ★ メソッド
   Accept		リクエストに応えてコネクションを開始する
   Close		コネクションをクローズする
   Connect	相手を指定してコネクションを開始する
   GetData		バッファからデータを取り出す
   Listen		ローカルポートで受信待ちを開始する
   PeekData	バッファのデータを見る
   SendData	データを送信する
   
  ★ イベント
   Close			コネクションがクローズされた
   Connect		コネクションが開始された
   ConnectionRequest	コネクションリクエストがきた
   DataArrival		データが届いた
   Error			エラーが発生した
   SendProgress		送信状態を通知する
  

  TCPコントロールは、送信も受信もできる。すなわち、これひとつあれば、クライ アント側もサーバー側もプログラムを作ることができるわけだ。一般的には、サー バーは常に動いているものであり、クライアント側からのリクエストによってさま ざまなサービスを行う。したがって、クライアント側とサーバー側で設定も異なる ということになる。次に、TCPコントロールのクライアント側とサーバー側の一般 的な設定の手順を示す。

  サーバー側

  1. LocalPortプロパティでローカルポートを指定する。
     このポートは、Windows NTで あれば、ファイルwinnt/system32/drivers/etc/servicesに記述してあるポートである。
     Windows 95のときには、windows/servicesである。servicesファイルは修正してポート を独自に追加すべきだが、これは特にしなくても動くことは動く。
     
  2. Listenメソッドを指定して受信を開始する
     
  3. ConnecttionRequestイベントが発生したら、引数のrequestIDをAcceptメソッドの引数として実行する。
     
  4. 必要に応じて、SendDataメソッドで送信する。
     

  クライアント側

  1. RemoteHostプロパティでサーバーマシンを指定する。
     
  2. RemotePortプロパティでサーバーマシンのポートを指定する。
     
  3. Connectメソッドを使ってコネクションリクエストを送る。
     
  4. サーバーからAcceptされたら、Connectイベントが発生する。
     
  5. 相手からデータが送られてきたら、DataArrivalイベントが発生するので、GetDataメソッドでデータを取り出す。
     
  6. Closeメソッドを使ってコネクションを終了する。
     

  サーバー側とクライアント側での対応を見ていけば、そんなに難しいことはないだ ろう。ここでは単純化してクライアントとサーバーに明確に分けたが、もちろんそ の両方となるようなプログラムを作ることはできる。また、このままでもクライア ント側からデータを送信することもできるし、受信もできる。要するに、クライア ントとサーバーの関係というのは、コネクションのリクエストの手順の問題なので ある。
  実際に、このコントロールを使ってプログラムを作るときに注意が必要なのは、 サーバー側でのコントロールの設定である。コネクションのリクエスト待ちのコン トロールと、実際に通信をするコントロールは別に用意しなくてはならないのだ。 これはコントロール配列として動的に増やしていけば、複数のコネクションを張る ことができる。
  実際に、こうした手順でクライアントとサーバーで単純に文字列を受け渡しするよ うなプログラムを作ってみた。クライアント側、サーバー側それぞれについてリス トと実行画面を示す。
  ところで、このようにTCP/IPで特定サーバーの特定ポートと接続できるということ は、すでにあるアプリケーション層の他のプロトコルも使おうと思えば使えるとい うことだ。たとえば、WWWサーバーのあるマシンを指定して、ポート80でコネクト すれば、HTTPで会話することができる。HTTPはごくカンタンなプロトコルだから、 「GET / HTTP/1.0」という文字列の後にCRをふたつ付けて送ってやれば、そのサーバ ーのホームページのHTMLを得ることができる(画面)。コネクションは、このHTML が送られた瞬間にクローズする。なるほど、こういうことだったかと納得できるの も、TCP/IPという比較的低レベルのプロトコルを使えばこそである。もし、元気が あれば、勝手に拡張したHTMLを作って対応するブラウザを作ることも可能である。

• UDPコントロールの使用法

  UDPは、不特定多数にデータを送りつけるというものだ。したがって、コネクショ ンのないぶんだけTCPよりもカンタンである。ただし、不特定多数というのは言葉 のあやであり、実際にはサブネットを考慮したリモートマシンのIPアドレスを指定 して、特定のサブネットにあるマシン全部にデータを送ることができる。
  もっとも、TCP/IPと違ってコネクションすらないのだから、確実に送られたという 保証は一切ない。ことによると、まったく届いていないということもありうるので 注意が必要だ。
  しかし、UDPを使えば、一対一でない通信をたやすく実現することができる。放送 のようなことをしたいのであれば、UDPが一番である。

  次に、UDPコントロールのプロパティ、メソッド、イベントを示す。

  
  ★ プロパティ
   LocalHostName	自分のマシンの名前を得る
   LocalIP		自分のマシンのIPアドレスを得る
   LocalPort		ローカルマシンのポート
   RemoteHost		リモートマシンのアドレス
   RemoteHostIP		相手マシンのIPアドレス
   RemotePort		リモートマシンのポート
   SocketHandle		ソケットのハンドル
   
  ★ メソッド
   GetData	バッファからデータを取り出す
   SendData	データを送信する
   
  ★ イベント
   DataArrival	データが届いた
   Error		エラーが発生した
  

  実際にUDPを使うには、コネクションのない分TCPよりカンタンであるが、やはり クライアントとサーバーという関係、というよりは送信側と受信側という関係はあ る。次にそれぞれの一般的な手順を示す。

  送信側

  1. RemoteHostプロパティとRemotePortプロパティを指定する。
     
  2. SendDataメソッドでデータを送信する。
     

  受信側

  1. LocalPortプロパティを指定する。
  2. 受信するとDataArrivalイベントが発生するので、GetDataイベントでデータを取得する。

  カンタンなUDPのサンプルプログラムのソースおよび実行画面を示す。

• TCPを使ったリアルタイム電子会議システム

  もうおわかりのように、TCPやUDPを使ったプログラミングは、これらのコントロー ルを使う限り、決して難しいことはない。ただ、現状のものではそれなりのクセや バグもあるので、慣れる必要はあるだろう。
  ここで、TCPを使ったイントラネット用ツールのプロトタイプとなるようなものを 作ってみた。題して、リアルタイム電子会議システム。果たしてその実態はという と、単なるテキストベースのチャットプログラムである。カンタンなものではある が、この方法をベースとしていけば、まったく独自のプロトコルを作ることができ る。
  もちろん、ここでもちょっとはプロトコルを作ってみた。題してSimple Chat Protocolである。話はカンタンで、クライアントは20001番のポートでサーバーに接 続する。サーバーはクライアントに接続許可を出し、さらにハンドル名をリクエス トする。ここでは、「TELL_ME_HANDLE」という文字列を送るだけである。これに 対応して、クライアント側では「/haハンドル名」という形でハンドルを送る。する と、サーバー側はチャットができるグループにクライアントを追加する。サーバー 側を終了すると、クライアント側にすべて通知する仕組みや、クライアント側から コネクションを閉じたときに、他のユーザーに通知する仕組みも入れてみた。 このシステムでは、サーバー側は単なるサーバーとして動作し、ユーザーはあくま でもクライアントプログラムを使うようにしている。結果的にプログラムは単純化 できるので分かりやすいし、拡張もしやすい。
  この他にも、クライアント側から文字列を送ると、サーバー側で一定の処理をする 仕組みをいくつかつけた。「/w」で接続中のユーザー一覧を返す。「/ha」では手動 でハンドルを変更することができる。また、BEEPを鳴らすというコマンドもつけて みた。リストおよび、実行画面を示す。
  このシステムはごく単純なものだが、チャットルームを増やすとか、部屋に入る権 限をつけるとかしていけば、パソコン通信のチャットシステム程度のものはスグに 作ることができるだろう。
  このようなチャットのシステムには、IRCというものがすでにあるが、これならイ ントラネットで使うこともできるはずだ。また、履歴をファイルに記憶しておけば 、後から入った人も過去の会議内容を知ることができる。
  今回は、文字列だけでいろいろなコマンドをサーバーに送って指示することができ るということで、チャットシステムを作ったわけだが、もっとガチガチにプロトコ ルを決めれば、特定の業務にだけ使うようなものも作れるハズだ。
  もちろん、RDBMSとの連携なども、RDOを使ったり、ちょっとした処理ならばDAO を使ってJETのDBにしてしまうことも可能だ。どちらかといえば、C/Sでのミドルウ ェアを自作するのに近いかもしれないが、Visual Basicだから、何でもありである。 従来のWWWサーバーでDBに接続できるタイプのものだと数十万円もしていたことを 考えれば、非常に安価に自由度の高いものを構築することができる。
  また、WWWとの連携を取ったりしても面白いだろう。今はWindows NTやWindows 95 用のWWWサーバーもあるのだから、DCOMを待つまでもなく、勝手なプロトコルで 勝手な処理を自由に追加することもできるというわけだ。
  このように、イントラネットはWWWだけではない。セキュリティなどを考えれば、 むしろ、こうした勝手なプロトコルこそイントラネット向きだと言えるだろう。
  インターネットの世界は、UNIXの世界から発展してきている。ソフトウェアは買 うのではなく、拾ってくるか、作る世界なのである。妙な売り物イントラネット開 発ツールなどに頼ると、明日はない。
  

酒井法雄ライブラリ
int21 ホームページ | PCDN ホームページ

---

Copyright (c) 1996 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp