モデムは、V.42bis という圧縮プロトコルを持っているので、DCE-DCE 間 (モデム−モデム間) の速度が 4 倍で転送される可能性はある。特にテキストデータは圧縮効率が高いので、スピードは上がる。
ただし DTE-DCE 間 (PC-モデム間) が DCE-DCE 間の 4 倍必要。
単純に 100BASE-TX の Hub に 10BASE-T の card を繋いた場合は出来ない。100BASE-TX は 100BASE-TX 用の HUB に、10BASE-T は 10BASE-T 用の HUB に繋ぎ、二つの HUB を10BASE-T/100BASE-TX ブリッジを使用して繋ぐ必要がある。
また、別の方法として 10/100 自動認識可能な HUB を買って、全部そこに繋いでもよい。
ハブが 4 台までというのは、「ある点からある点までで 4 台を越えてリピータ (ハブ) を通過できない」と言う意味で、4 段まで直列にハブをつなぐ方式の場合である。もし段数を越えて接続すると、CRC エラーを多発し LAN が遅くなるのは必定と考えた方が良い。そのため、要の所に bridge HUB を置く等して工夫する。
また、最も沢山のハブが集まっているハブをスィッチングハブに替えれば、スィッチングハブはリピータではないので、1 段としてカウントされない。
ポート数を増やしたいだけならスタック接続と言う方式もある。ハブの位置を離すことはできないが、ハブの台数をあまり気にせずポート数を増やすことが可能。ただし、この方式も各メーカーの独自の規格のため、既存のハブにスタック接続できる環境があることと、そのメーカー専用のスタックケーブルが必要といった前提条件がつく。
まず、各部屋へ配線 (10BASE-T など) するにあたって、寮の管理者に許可をもらう必要がある。
月々の料金 3万 8千円も 10 人ほど集まれば現実的な金額になるが、寮のメンバーが入れ替わり、接続したい人数が減ったときにどうするか、また、メールサーバ、ネームサーバを寮側におく場合、誰が運用するのか、その人が引越したときどうするか、などなど、接続よりも重要な問題が結構ある。
ネームサーバ、メールサーバを自前で持つと自由が利き、IP アドレスも 16 個使えるので有利だが、上記を考慮するとメールサーバ、ネームサーバは OCN 側のものを利用する方が無難かもしれない。
OCN で割り当ててくれる IP アドレスの数が足りないようであれば、足りない分は IP Masquarade とかする必要がある。サーバに Linux を導入して IP Masquarade してもよいし、RT80i などといった安いルータで IP Masquarade してもよい。
OCN エコノミーについては、 http://www.ocn.ne.jp/ocnweb/service/eco/index-e.html に詳しく載っている。
原因は様々考えられる。例えば以下の原因。
また、ISDN でも 64K で継ぐ分には 33.6K モデムのたかだか「倍」でしかないので、体感速度はあんまりかわらないように感じられるかもしれない。
さらには、マザーボードが原因で遅くなることもあり、マザーボードを交換したら早くなるケースもある。
ISDN とモデムの実効速度を比較するには、ftp で実際にファイル転送してみるのが最もてっとり早い。送るファイルは gzip されたものがいいだろう。
OS が Windows95 だとすると確認すべきと思われる事項は、
『電話等のアナログ機器を接続する回線』というより『アナログ or ディジタル公衆回線』という方が正確。専用線は専用であり、公衆網を利用したいならば別途公衆回線 (加入電話・ISDN 等) を用意する必要はある。
専用線といっても 128K までは同じメタル線を使うので、宅内の配線工事内容は、電話回線をもう一本引き込むのとそう変わらない。
なお、日本テレコムが多重アクセスサービスを開始する。局から宅内まで光で引き込んで、それを宅内で専用線、公衆回線、フレームリレーなどに分けて提供する。アクセスラインが 1 本で済む分、別々にたくさん引き込むよりも割安な料金設定になるとのこと。
ちなみに、高速ディジタル専用線 (ディジタルアクセス除く) では、多重化や分岐サービスを受ければ一本の光ファイバで複数拠点結べるといえば結べるし、料金も割引される(多重アクセス対応の機器が必要)。
ポイントツーポイントの個所に（専用線に） データ伝送とアナログ伝送を同時に乗せたいということであれば、アナログ専用線を使えばよい。オプションで、データと音声の同時伝送可能。
http://www.fujitsu.co.jp/hypertext/cont/modem/m-plx2.html
D チャネルの呼制御信号の呼設定の中に高位レイヤ整合性という情報要素があり、この中身でファックスかどうか判断できる。ただし、NTT は設定してくれないはずなので相手も ISDN で相手の端末 (または TA) が設定してくれないとだめ。
FAX と TEL の着信識別をしたいのならば、ダイヤルイン機能を用いて TEL と FAX に別々の電番を持たせて、鳴り分けさせるのが一般的で、リーズナブルである (工事費 700円、月額 900円)。
ネットワークカードには自分宛てのパケット以外も拾える「無作為抽出モード (プロミスキャスモード)」を持つものがあり、この機能でネットワークを流れる全てのパケットを拾っている。最近の NIC は大抵は持っており、プロミスキャスモードに対応した NIC なら全てのパケットを拾える。
ただし、NIC やドライバの組み合わせでプロミスキャスモード非対応になるケースがある。例えば、CONTEC 製 C-NET(PC)C の NIC は、Windows3.1 のときはプロミスキャスモードだったが、Win95 になってドライバが変わり、プロミスキャスモードでなくなったとのこと。
インターネットに繋がなければ、プライベートではない IP アドレスにしても不具合はない。今後も確実にインターネットに繋がないのであれば、IP アドレスに何を使っても問題は無いだろう。
しかし、例えばファイアウォールを介してインターネットに繋がるようにすると、外と内で同じ空間がある場合にファイアウォールがそのアドレスを持つパケットをどちらに投げれば良いか分からない、といった不具合が発生する。
10BASE-T の場合、スイッチング HUB ではない普通の HUB(Repeater) の制限は 4 台までであるが、スイッチング HUB はリピータではないので、この制限は関係ない。また、混在時の HUB の数え方としては、スイッチング HUB でそれまでの通ってきた HUB の台数が 0 になると計算すれば良い。
衝突発生から再送までの時間の決定は IEEE802.3 で、以下のように規定されている。
再送までの時間 = ([0, 2^Min(衝突回数, 10)] の範囲の一様乱数) * スロット時間 (512ビット時間)
この式は決まっているものなので、LAN カードやドライバによって再送までの時間の計算方法が違うということはあってはいけないことである。
衝突は相手がいなければ起きないことなので、例えばコリジョン発生後の再送までの時間を常に短くしてしまうような端末が複数存在したり，完全に疑似乱数列が等しく、再送までの時間が同期しているような端末が互いに衝突するようなケースでは衝突は頻発するだろう。実際、80 年代にあった実装で、乱数を使わずに、衝突を起こした端末同士がきっちり 2 の N 乗の単位時間後に再送をしてしまうというものがあったらしい。(当時はマシンの能力も低かったので、ネットワークに対してシリアスにならなくても済んでいた)。
ある特定の端末に限って頻繁に衝突を繰り返すということは、LAN カードやドライバに起因するというよりは、単にその端末から発生するトラヒックが異常に多いと考える方が妥当である。また、経験上、特定のマシンだけネットワーク側で衝突が発生するような振る舞いをする時は、十中八九、物理的な接続が悪かったり、壊れていたりするパターンである。
状況による。
現状で存在する IP アドレスの使われ方としては、以下の方法があり、どのような状況で IP ネットワークを作成するかとか、どのような機器が存在するかによって、いずれを選択するか (できるか) は決まって来るだろう。
今時の機器は少なくとも 2. までは対応しているはずである。また、CIDR が一般化したので、2. においても、サブネット部のビットが全て 1 や 0 の場合も使用できる場合が多い。しかし現実には、機器の対応や「おまじない」的な設定が必要なものもあるので、注意が必要。
例えば、比較的新しい IOS の載った Cisco のルータは、全て 1 や 0 のサブネットをデフォルトでは扱えない。設定のコマンド (おまじない) が必要である。
IP アドレスは、ルータとかホストではなく、それらのネットワーク・インターフェイスが持つものである。
unnumbered link の場合、ルータ間のシリアル回線、またはルータのシリアル・インターフェイスでは IP アドレスを持たない。しかし、ルータ自体は他のインターフェイスのどこかに IP アドレスを持つはずである。
NIC 上の EEPROM に書き込まれている MAC アドレスを書き換えることができる NIC は存在するが、EEPROM を書き換えるツール等は一般的には売られていない。しかし、MAC アドレスを書き換えるのではなく、動作するときの MAC アドレスを変更できる NIC は珍しくないだろう。
例えば、多くの NIC で採用されている Intel のイーサチップ 8255x シリーズには、MAC アドレスを記憶しておくための ROM がついているが、この内容がそのまま動作時の MAC アドレスとして利用されるわけではない。動作時の MAC アドレスを保持しているレジスタは独立して存在しており、デバイスドライバが初期化処理において ROM から MAC アドレスを読み出して、MAC アドレスレジスタに設定することによって両者が一致している。
上記の NIC の場合、Intel の出している Win9x/NT 用のデバイスドライバであれば、レジストリ変えるだけで動作時の MAC アドレスを変更することが可能である。
また、DECnet のように MAC アドレスを変更できないと困るプロトコルも希に存在する。SunOS も 4.1.X の途中あたりで、OS が MAC アドレスを変更する機能をサポートしたという経緯もある。
Full Duplex : 全二重、送信しながら受信できる
Half Duplex : 半二重、受信している間は送信できない/送信している間は受信できない。
例えばイーサネットの場合、そのバスの使用権をもつ、つまりバスにデータを流す事ができるデバイスは 1 つである。通常は、あるデバイスがデータを送信しつつ他のデバイスからのデータを受け取るという事、つまり複数のデバイスがデータを流すという事はできない。複数のデバイスがデータを流すことを、衝突、コリジョン (collision) という。従ってイーサネットの一般論からすれば、通信方法は Half Duplex に限定される。
一方、10BaseT や 100BaseTX などの撚り線を使ったものに限定すると話が変わり、10BaseT や 100BaseTX では、送信用、受信用の線が１対づつ独立して存在する。従って、送信用、受信用の対をハブが混ぜ合わせる事が無ければ、デバイスは送信と受信を同時にできる。これが Full Duplex である。
Full Duplex であるためには、ハブが交換機の機能を持つ必要があり、この機能を持つハブを称してスイッチングハブと呼ぶ。(実際はスイッチではなく、NIC の化け物のようなものが大多数)。
イーサネットスイッチに直接ホストを接続した場合は、ほとんどの場合スイッチとネットワークカードの間でネゴシエーションして、Full Duplex に設定できるなら Full Duplex、できなければ Half Duplex に自動的に設定される。
全てのイーサネットスイッチが全二重と言うわけではなく、半二重にしかできないイーサネットスイッチもある。また、ネゴシエーションがうまく行かずに不整合が起きるときもある。ネゴシエーションがうまく行かない場合は、自動設定を切って固定設定にすればよい。なお、Duplex の不整合が起きると一般にスループットが格段に落ちる。
Full と Half では、Collision の検出方法とその後の動作が若干違うはずなので、ハブ側の対応だけでなく、NIC 側の対応も必要である。Full がその NIC で可能かどうかは、チップセットの問題で、もう値段とは関係なくなっている。\980 の極安物 ISA-NIC で Full Duplex に対応しているものもある。
Full Duplex で動いているか Half Duplex で動いているかは、NIC から情報が取れるはずで、スイッチングハブにぶら下げた時の状態を調べれば、NIC 自体が対応しているかどうかが間接的に分かるだろう。他に調べる方法は色々あるが、製造元に問い合わせる、チップセットのスペックを調べる、などが比較的簡単な方法である。
ルータの実装にもよるため、一般的にそう言ってしまうのは嘘である。RFC1812 "Requirements for IP Version 4 Routers" には、unnumbered の時の IP broadcast の扱いについて判断できるような記述が見当たらないため、実装依存といえそうである。ただ、ルータは通常インターフェース毎にブロードキャストドメインを分割するものなので、一般的にはあり得ないと思われる。
なお、WAN 側に IP アドレスを振らない設定で、LAN 側のブロードキャストが中継されるというのは、以下の例の誤解ではないかと考えられる。
CISCO のルータの設定を例にすると、
interface ether 0
ip address 192.168.1.1
ip broadcast address 192.168.1.255
interface serial 0
ip unnumbered ether 0 <--- アドレスを付与しないので、送信パケットの
アドレスを借用するインタフェースを指定。
ip broadcast address xx.xx.xx.xx <-- ブロードキャストアドレスを指定する。
上記のように、回線側のブロードキャストを指定するのだが、この指定アドレスの解釈にCISCO の OS のバージョンによって微妙な違いがある。あるバージョンでは、送信するブロードキャストは、192.168.1.255 (上記の設定例の場合) になり、相手からのブロードキャストと異なるので、xx.xx.xx.xx には相手のブロードキャストアドレスを指定する、という設定になる。
従って、unnumbered の設定をしたインターフェースに設定するブロードキャスト (xx.xx.xx.xx) は、それぞれ相手の LAN 側のブロードキャストを指定するという変な設定になっていた。(つまり、送信と受信で別のブロードキャストアドレスを使用することになる)。しかし、あるバージョンでは送受信するブロードキャストは設定どおり、xx.xx.xx.xx になる。
RIP を例にすると、ポイントツーポイント接続で相手の IP アドレスが分からない場合、unnumbered の時にルータが出す RIP の宛先 IP アドレスはブロードキャストしかない (相手のアドレスがわからないため)。unnumbered では、アドレスが設定されていないので、ルータが出すパケットの送信元アドレスは LAN 側のアドレスを借用する事になる。上述した CISCO の前者の実装の場合、LAN 側のブロードキャストアドレスが使用されることになる。これを表面だけ見ると、LAN からのブロードキャストが回線側に中継されていると勘違いするかもしれない。
RFC1122 Requirements for Internet Hosts -- Communication Layers によると、
3.2.2.6 Echo Request/Reply: RFC-792
...
An ICMP Echo Request destined to an IP broadcast or IP
multicast address MAY be silently discarded.
なので、反応しなくても正しい挙動である。ただ、不便であることには間違い無いだろう。