Mirror of JVM's Blog: 2007

2007년 12월 20일 목요일

Why 3-way Handshake is needed for TCP?

A Connection-Oriented Protocol, such as TCP, exchanges Control Information(called a Handshake) with the remote computer to verify that it is ready to receive data before sending it. When the handshaking is successful, the computers are said to have established a connection.
In contrast, a Connectionless Protocol, such as IP, doesn't exchange Control Information to establish an end-to-end connection before transmitting data.

TCP Connection Establishing: 3-Way Handshake

TCP Connection이 성립되기 위해서는 먼저 Server가 Connection을 수락할 준비상태에 들어가 있어야 하는데, 이를 'Passive open'이라 한다. Client는 Server로의 Connection Establishment를 요구하며, 이것은 'Active open'이다.

1. SYN Segment(Client의 Synchronization Information 전송): Client는 Source Port에 자신을 나타내는 Port Number를 넣고, Destination Port에는 Server를 가리키는 Port Number를 넣는다.(그림에서 Destination Port가 23이므로 Telnet Server로 Connection Request하는 경우이다). Sequence Number에는 Client의 ISN(Initialization Sequence Number)를 넣고, Acknowledgment Number는 0을 넣고, Flag는 SYN bit를 1로 설정하여 전송한다.

2. SYN+ACK Segment(Server의 Synchronization Information 전송 + SYN Segment 수신 확인): Server는 Source Port에 자신을 나타내는 Port Number를 넣고, Destination Port에는 Sender를 나타내는 Port Number를 넣는다.(Telnet Server를 예로 들고 있으므로 Source Port에는 23번이 들어간다, Sender의 Port Number는 첫번째 단계에서 수신한 SYN Segment에서 알 수 있다. 결과적으로 보면 Sender가 보낸 SYN Segment에서 Source Port와 Destination Port가 서로 바뀌어 들어간 것과 같다). Sequence Number에는 Server의 ISN를 넣고, Acknowledgment Number에는 “Client의 ISN + 1”의 값을 넣고, Flag는 SYN 와 ACK bit를 모두 1로 설정하여 전송한다.

3. ACK Segment(SYN Segment 수신 확인): Client는 첫번째 단계와 동일하게 Source Port와 Destination Port를 설정하고, Acknowledgment Number에는 “Server의 ISN + 1”의 값을 넣고, Flag는 ACK bit를 1로 설정하여 전송한다.

Why 3-way Handshake is needed for TCP?

TCP is a connection oriented protocol. It has to establish a connection between two parties (host and server) before it can start transmitting data (as opposed to for example, IP). The 3-way handshake verifies that both ends are connected properly.

2007년 12월 15일 토요일

Dynamips / Dynagen Tutorial

Dynamips / Dynagen Tutorial
Documentation Revision 1.11.2

한 블로그에서 Tutorial의 번역판을 우연히 찾게 되었다.
번역이 불완전하긴 하지만 원본의 문서가 양이 많아서 읽어보려면 상당한 시간이 걸리므로
우선은 시간을 좀 절약할 수 있지 않을까 해서 스크랩해둔다.
이것은 Documentation Revision 1.9.1을 번역한 것이다.

more..

2007년 12월 13일 목요일

Cisco 7200 Simulator - Dynamips

[Project Homepage]

Introduction

The Project was started in August 2005 to emulate a Cisco 7200 on a traditional PC.
Now, it also supports Cisco 3600 series (3620, 3640 and 3660), 3700 series (3725, 3745) and 2600 series (2610 to 2650XM, 2691).

The goals of this emulator are mainly:

* To be used as a training platform, with software used in real world.
* Test and experiment the numerous and powerful features of Cisco IOS.
* Check quickly configurations to be deployed later on real routers.

Of course, this emulator cannot replace a real router: you should be able to get a performance of about 1 kpps (depending on your host machine), to be compared to the 100 kpps delivered by a NPE-100 (the oldest NPE model). So, it is simply a complementary tool to real labs for administrators of Cisco networks or people wanting to pass their CCNA/CCNP/CCIE exams.

Current status

At this time, the emulator I have programmed is able to boot a large number of Cisco IOS releases available for the 7200, 3600, 3700 and 2600 platforms, including the latest 12.2S and 12.4T.

The following devices are emulated in the current release (0.2.7):

MIPS64 and PowerPC CPU processors. The instruction sets are not completely emulated now (MIPS FPU support is lacking, TLB support is not finished and other minor things), but it is sufficient for IOS ;
DRAM and Packet SRAM memory ;
Non-Volatile Memory (NVRAM) ;
Signetics SCN 2681 DUART (C7200 Console and AUX ports) ;
National Semiconductors NS16552 DUART (C3600/C3700/C2600 Console and AUX ports) ;
Dallas DS1620 Temperature Sensors and Voltage Sensors, allowing the C7200 Environmental Monitor to work properly ;
NMC93C46 Serial EEPROM ;
Bootflash of 8 Mb (Intel 28F016SA) ;
Galileo GT64010/GT64120/GT96100 PCI controllers, DEC 21x50 PCI bridges and so ;
PCMCIA ATA disk emulation (C7200 only at this time).
...

The following Cisco 7200 Port Adapters (PA) are currently supported:

FastEthernet cards "C7200-IO-FE" and "PA-FE-TX" based on DEC21140 chip
FastEthernet cards "C7200-IO-2FE" and "PA-2FE-TX" based on Intel i8254x chips
GigabitEthernet cards "C7200-IO-GE-E" and "PA-GE" based on Intel i8254x chips
Ethernet cards "PA-4E" and "PA-8E" based on AMD Am79c97x chips
ATM card "PA-A1" based on Texas Instruments Tneta1570 chip
Serial cards "PA-4T+" and "PA-8T"
POS (Packet over SONET) card "PA-POS-OC3" (experimental, only works with recent IOS images)

The following Cisco 3600 (3620,3640,3660) Network Modules (NM) are currently supported:

Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX", all based on AMD Am79c97x chips
Ethernet switching module: "NM-16ESW"
Serial card "NM-4T"

The following Cisco 2691/3725/3745 Network Modules (NM) are currently supported:

FastEthernet cards: "NM-1FE-TX"
Ethernet switching module: "NM-16ESW"
Serial card "NM-4T"

The following Cisco 2600 Network Modules (NM) are currently supported:

Ethernet cards: "NM-1E", "NM-4E" and "NM-1FE-TX"
Ethernet switching module: "NM-16ESW"

Lab simulation / "Hypervisor" mode

It is now possible to run the emulator as an "Hypervisor" to start and control many virtual router instances simultaneously.

Dynagen, is a front-end (written in Python) that makes lab simulation with the hypervisor very easy: it uses an INI-like configuration file to provision Dynamips emulator networks.
It takes care of specifying the right port adapters, generating and matching up those pesky NIO descriptors, specifying bridges, frame-relay, ATM switches, etc.
It also provides a management CLI for listing devices, suspending and reloading instances, etc.
You can also distribute virtual instances across different servers to set up complex labs. To begin with Dynagen, you can consult this very complete tutorial.

Dynagui is a graphical front-end. It uses Dynagen to communicate with the hypervisor.

How to use it ?

Very important remark: by default, an instance will take 100% of the host CPU.
To avoid this, please read the "idle-pc" section in the README.

Help for Cisco router simulator (dynamips-0.2.8)

Emulated hardware
The emulator currently supports the following platforms:
   - Cisco 7200 (NPE-100 to NPE-400)
   - Cisco 3600 (3620, 3640 and 3660)
   - Cisco 2691
   - Cisco 3725
   - Cisco 3745
   - Cisco 2600 (2610 to 2650XM)
   - Cisco 1700 (1710 to 1760)

By default, a Cisco 7206VXR with NPE-200 (256 Mb of DRAM) is emulated.
To emulate another platform, use the "-P" command line option
(for example, "-P 3725" or "-P 3600").

For the 7200, you can change the NPE type with the "-t" option.
It is possible to select "npe-100", "npe-150", "npe-175", "npe-200", "npe-225", "npe-300" and "npe-400". The "npe-g1" is not working.

For the 3600, a 3640 with 128 Mb is emulated by default.
You can change this with the "-t" option and by specifying "3620" or "3660".
Don't forget to set the chassis type depending on your IOS image, a c3660 image will not run on c3640 hardware and vice-versa.

Remark: PCMCIA card emulation is not supported yet with Cisco 3600.

Command Line Options details
--idle-pc <pc> :
The "idle PC" feature allows you to run a router instance without having a 100% CPU load. This implies that you can run a larger number of instances per real machine.
To determine the "idle PC", start normally the emulator with your Cisco IOS image, and a totally IOS empty configuration (although not mandatory, this will give better results).
When the image is fully booted, wait for the "Press RETURN to get started!" message prompt, but do not press Enter key.
Wait about 5 seconds, then press "Ctrl-] + i".
Some statistics will be gathered during 10 seconds.
At the end, the emulator will display a list of possible values to pass to the "--idle-pc" option.
You may have to try some values before finding the good one.
To check if the idle PC value is good, just boot the Cisco IOS image, and check your CPU load when the console prompt is available.
If it is low, you have found a good value, keep it preciously.
Important remarks:
* An "idle PC" value is *specific* to a Cisco IOS image.
   You cannot boot a different IOS image without proceeding as described above.
* Do not run the process while having the "autoconfiguration" prompt.

To boot quickly, the preferred method is to decompress the IOS image with the "unzip" utility.
It avoids to run the self-decompressing process in the emulator.

$ unzip -p c7200-advipservicesk9-mz.124-9.T.bin > image.bin
warning [c7200-advipservicesk9-mz.124-9.T.bin]:  27904 extra bytes at beginning or within zipfile
  (attempting to process anyway)
$ file image.bin
image.bin: ELF 32-bit MSB executable, cisco 7200, version 1 (SYSV), statically linked, stripped

You can ignore the warning, unzip has just skipped the self-decompressing code at the beginning of the image.

Cisco 7200 Simulator FAQ

2007년 12월 6일 목요일

DynDNS의 WebHop Redirect Service 이용하기

www.dyndns.com에 Log-in합니다.

좌측메뉴에서 Host Services항목을 선택합니다.

Add New Hostname click하면 아래와 같이 나옵니다.

먼저 Service Type항목에서 WebHop Redirect를 선택해줍니다.

그럼 아래쪽에 WebHop Settings항목이 나타납니다.

우선 Hostname에는 새로이 사용할 주소를 지정해줍니다.

그 다음 WebHop Settings의 Redirect URL에 위에서 지정한 주소를 이용해

접근해야할 URL을 입력합니다.

http://mydyndns.homeip.net:8080/ 과 같이 Port Nr.도 함께 지정해 줍니다.

Yes, cloak this page항목을 체크하면 실제주소가 보여지지 않고

Cloaked title에 지정한 내용을 보여주게 됩니다.

Creat Host를 누르면 설정완료입니다.

이제 http://mydyndns.homeip.net:8080/ 대신 Web Browser의 주소창에

위에서 지정한 주소를 입력해주면 됩니다.

2007년 11월 29일 목요일

Network Selfstudy

후니의 네트워크 이야기 컬럼의 내용을 기반으로 내용을 보충해 넣은 자습용 문서이다.
아직은 기초적인 내용들만이 담겨져 있지만 계속 추가해 나갈 예정이다.
LAN, MAN, WAN, OSI Reference Model, TCP/IP Model, Ethernet,
Network Cable, Hub, Bridge, Switch, Router 등에 관한 내용들이 담겨있다.

Network Self-Study - secured.pdf

ver.0.1.1 Page 5 오타수정.
ver.0.1.2 Page 8 Graphic수정.

secure.pe.kr의 강의실에 공개되어 있는 강좌들 중
TCP/IP Protocol Suite와 IP Address에 관한 부분을 정리한 자습용 문서이다.
위의 문서에 비해서는 추가된 내용이 적다. 그만큼 내용이 충실한 강좌였기때문이기도 하다.

TCP-IP Protocol Suite - secured.pdf

IP Address - secured.pdf

2007년 11월 26일 월요일

[Terms] STP(Spanning Tree Protocol)

[Source] Terms Korea

STP는 동일한 두 개의 Computer Network Segment를 서로 연결하기 위해 두 개의 Bridge가 사용된 곳에서 Bridge 간에 정보를 교환할 수 있도록 함으로써, 주어진 Message를 둘 중 오직 한 개의 Bridge만이 처리할 수 있도록 해주는 Protocol이다.

STP는 흔히 'Bridge Loop'라고 알려져 있는 상황을 예방한다.

1. Bridge Loop Caused by a Workgroup Bridge Connected to the Wired LAN

2. Bridge Loop Caused by Two Workgroup Bridges on the Same Remote Hub

Ethernet이나 Token Ring과 같은 LAN에서, Computer는 공유하고 있는 전송로를 서로 먼저 사용하기 위해 경쟁한다. 만약 너무 많은 수의 Computer가 동시에 Data를 전송하려 시도하면, Network의 전반적인 효율이 악영향을 받을 수 있으며 심지어 Traffic 전달이 거의 멈추는 지경에 까지 이를 수 있다.
이러한 개연성을 최대한 줄이기 위해, Bridge라고 불리는 장치를 이용하여 LAN을 두 개 이상의 Network Segment로 나누게 된다. 이로 인해 각 Message는 원하는 목적지로 가기 전에 Bridge를 통과하게 되는데, 이때 Bridge는 그 Message를 송신측이 속해있는 동일 Segment 내 어딘가로 보내야 할지, 아니면 다른 Segment로 보내야 할지를 결정하게 된다.
Bridge는 수신측 주소를 보는 것 외에 어떠한 일도 하지 않으며, 자신이 미리 알고 있는 정보에 기반하여 받은 Message를 올바른 경로로 전달하기만 한다. Network Segment와 Bridge 이용의 장점은 Network 경로를 사용하기 위해 벌어지는 경쟁을 절반 이하로 줄임으로써, Network이 멈출 가능성을 현저하게 줄이는데 있다.

각각의 Bridge는 양측 Segment트 간에 교환하게 되는 최초 Message와 Message에 응답한 Computer를 인식하고 기록해 놓는 등의 후속 행위를 통해, 어느 Computer가 어느 Segment에 속해 있는지를 지속적으로 학습(Leaning)하게 된다. 따라서 Bridge는 점차 어느 Computer가 어느 Segment에 속해 있는지 그 자체에 대한 그림을 스스로 구축하게 된다.
Bridge는 두 번째 이후의 Message가 전송될 때부터, 그 Message를 어떤 Segment로 전달할 것인가를 결정할 때 자신이 갖고 있는 표를 참조하게 된다.
경험을 통해 Bridge가 Network을 학습하게 하는 이러한 접근 방식을, 관리자가 따로 Bridge브리지 설정을 할 필요가 없는 형식의 Bridging이라는 의미로 ‘Transparent Bridging(투명한 브리징)’이라고 부른다.

Network 내에 Bridge를 설치할 때에는, 고장에 대비하여 Back-up용 Bridge를 추가하는 것이 보통이다.
Message 전송은 실제로 Main Bridge(Root Bridge)가 담당하지만, Main Bridge(Root Bridge)와 Back-up Bridge 모두는 지속적으로 Network 형상을 파악하고 있어야 한다. 그리고 두 Bridge는 서로 어떤 Bridge가 Main Bridge(Root Bridge)인지를 알 수 있도록 하기 위한 방법이 필요하다.
이를 위하여 두 Bridge 간에는 BPDU(Bridge Protocol Data Unit)를 이용하여 정보를 교환하기 위해 별도의 경로를 통한 접속을 갖고 있다.

각 Bridge 내의 Program이 그 Protocol을 어떻게 사용할지를 결정할 수 있도록 해주는 것을 Spanning Tree Algorithm이라고 부른다.
이 Algorithm은 특히 Bridge Loop, 즉 한 Segment에서 다른 Segment로 연결되는 경로를 다중화하면 무한 Loop가 생기는 상황이 벌어지지 않도록 고안되었다. 이 Algorithm은 Bridge가 다중 경로를 가지고 있을 때, 그 중 가장 효율적인 경로를 사용하도록 할 책임이 있다. 만약 최적의 경로를 이용할 수 없는 상황이 생기면, Algorithm이 새로 계산하여 차선의 경로를 찾는다.

STP가 Network을 결정하고 나면 BPDU를 이용하여 이 Data를 교환하는데,
이 작업은 다음의 두 단계로 나뉘어 진다.

1 단계: Algorithm은 수신된 설정 Message를 평가하고 제일 나은 선택 사항을 고름으로써 Bridge가 보낼 수 있는 최적의 Message를 결정한다.

2 단계: 특정 Bridge가 보낼 수 있는 최적의 Message를 선택한 후, Root 접속이 아닌 곳에서 받은 설정 Message와 Algorithm이 선택한 내용을 서로 비교한다. 이때, 만약 1단계에서 선택한 Option이 Root 접속이 아닌 곳으로부터 받은 내용보다 못하면, Algorithm은 그 Port를 제거한다.

STP는 IEEE의 한 위원회에 의해 개발되었다. IEEE는 현재, 기존의 STP에 Network 복원시간을 줄일 수 있도록 품질 향상에 주력하고 있는데, Link 상태의 고장 또는 변경 후 30~60 초 내의 시간을 10초 이내로 줄이는데 목표를 두고 있다.

Example:

Bridge에 내장된 STP를 이용하여 Network을 이중으로 구성, Network의 단절을 방지.
전송로 A와 전송로 B구간의 Wireless구간은 정상연결상태.
Packet은 전송로 A 또는 B 한쪽으로만 송수신.
전송로 A구간에 장애 발생시 자동으로 전송로 B구간으로 절체(Change Over)되어 Packet 송수신.

[cisco.com] Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches

2007년 11월 22일 목요일

[scrap] 화보로 보는 네트워크 기초 | 라우터의 이해

[Source] 앞서가는 네트워커를 위한 기술 활용전문지 온더넷 / 출판일 :2005년 11월호 / 박재곤 기자

화보로 보는 네트워크 기초 | 라우터의 이해

PC마다 LAN 카드를 장착하고, 이들을 허브나 스위치로 연결했다고 이것이 인터넷에 연결되는 것을 의미하지는 않는다. 라우터는 이렇게 허브나 스위치로 연결된 내부 LAN을 바깥 세상, 즉 인터넷과 연결시켜주는 역할을 하는 장비다. 때문에 인터넷을 기반으로 하는 오늘날의 네트워크 환경에서 인터네트워킹 장비인 라우터를 이해하는 것은 네트워크를 이해하는 좋은 방법의 하나가 될 것이다.

라우터(Router)는 이름 그대로 네트워크와 네트워크 간의 경로(Route)를 설정하고 가장 빠른 길로 트래픽을 이끌어주는 네트워크 장비다. 우리말로 풀어보면 '경로설정기'라고 할 수 있을 것이다.
인터넷, 다시 말해 IP 네트워크가 모든 네트워크의 기본이 되면서 라우터는 네트워크의 가장 핵심 장비로 등극했다. 인터넷이 확산되기 이전에는 사실 네트워크 자체가 확산되지 않은 상태이긴 했지만, 우리보다 네트워크의 역사가 오래된 해외의 경우를 보더라도, 과거 기업 단위 LAN 환경의 핵심은 스위치였다. 네트워크 내를 흐르는 트래픽의 대부분이 내부 LAN에서만 움직였기 때문에 스위치를 넘어 데이터가 전달되는 비중이 많지 않았기 때문이다. 내부 LAN 밖으로 데이터가 나가는 경우는 본사와 지사를 연결하는 전용회선을 통하는 경우가 전부였다.
하지만 인터넷 기반의 네트워크 환경에서는 어떤 형식으로든 네트워크가 외부의 다른 네트워크와 연결돼야 하고, 이를 위해서는 서로 다른 네트워크 간을 연결하는 장비인 라우터의 비중이 높아질 수 밖에 없게 된 것이다. 물론 라우터가 IP 네트워크 만을 위한 장비는 아니지만, 여기서는 최근의 네트워크 환경과 이해의 편의를 위해 인터넷 환경에 한정해 살펴보겠다.

라우터는 인터네트워킹 장비다
인터넷에 연결된 개별 네트워크의 수는 이루 헤아릴 수 없이 많은 것이 사실이다. 인터넷의 어원이 인터네트워크(Internetwork)에 있듯이, 라우터는 이렇게 서로 연결된 네트워크(Internetwork) 간의 경로(Route)를 설정해주는 장비다. 라우터가 '경로'에 비중을 둔 이름을 갖게 된 것도 이렇게 수없이 연결된 네트워크 간을 어떻게 연결하는 것이, 다시 말해 어떤 경로로 연결하는 것이 가장 효율적인가를 알려주는 길잡이 역할이 중요하기 때문이다.
라우터의 이런 인터네트워킹 기능은 OSI 참조모델로 살펴보면 훨씬 명확하게 이해할 수 있다. 허브나 스위치가 OSI 참조모델 2계층, 데이터 링크 계층에 속하는 반면, 라우터는 3계층, 즉 네트워크 계층에 해당하는 장비이다. 잘 알려진 대로 네트워크 계층은 여러 개의 독립적인 네트워크 간에 데이터를 전송하는 것에 관한 계층이다.
허브나 스위치가 속해 있는 데이터링크 계층의 데이터 전송은 물리적인 장치의 주소 지정에 의해 단일 네트워크로 연결된 모든 장치에 데이터를 브로드캐스팅하며, 수신측 장비에서 확인해 자신에게 오는 데이터를 수신받는 방식이다. 이런 방식은 일정한 범위와 크기의 내부 LAN에서는 가능하지만, 네트워크의 규모가 일정 크기를 넘어서면 매우 비효율적인, 그리고 현실적으로 운영할 수 없는 네트워크가 되고 만다. 광대한 인터넷을 향해 브로드캐스팅을 한다는 것은 누가 생각해도 합리적이지 못한 방법이다.
그러나 네트워크 계층의 장비인 라우터는 여러 개의 네트워크가 연결된 환경에서 특정 경로를 선택해 데이터가 전송되도록 한다. 이는 목적지로 데이터를 전송하면서 목적지가 아닌 네트워크에 데이터가 전송되는 것을 방지할 수 있다. 여기서 특정 경로란 다양한 라우팅 알고리즘을 통한 최적의 경로를 말한다.

라우터는 컴퓨터다
라우터의 기본적인 구성은 일반 컴퓨터와 마찬가지다. 중앙처리 장치인 CPU가 있고, 각종 메모리가 라우터의 운영체제와 환경설정 정보, 그리고 라우팅 정보 등을 담고 있다. 그리고 네트워크 인터페이스를 통해 트래픽을 입출력한다. 때문에 초기에는 소규모 환경에서 값비싼 라우터 장비 대신 일반 PC 서버를 이용해 라우팅 서비스를 구현하는 경우도 적지 않았다.
CPU는 라우터의 성능(처리량)을 결정짓는 부분이기 때문에 소형 라우터보다 중형 라우터가 더 빠른 CPU를 내장하고 있으며, 사용자가 많거나 더 많은 작업을 할수록 메모리 용량이 커야 한다.
라우터의 메모리에는 라우터 운영체제(예를 들면 시스코의 IOS)와 라우터의 환경 설정에 대한 내용 즉, 라우터 비밀번호, 시리얼 포트의 속도, 포트에 등록된 IP 어드레스 등의 내용이 저장돼 있다. NVRAM( Non-Volatile Random Access Memory)을 사용하기 때문에 라우터를 재부팅해도 수정된 환경이 적용된다.
라우터는 ROM에 있는 부트스트랩 프로그램을 통해 플래시 메모리에 라우터 운영체제를 저장하고 있다가 메모리로 올린다. 네트워크 운영체제는 기능이 향상되고, 제공하는 기능이 많아질수록 버전이 올라가는데, 이때 프로그램 크기도 점차 커지므로 이를 저장하고 운영하기 위한 메모리도 커진다. 따라서 네트워크 운영체제의 버전이나 장비에 따라 필요한 플래시 메모리 용량이 다르다. 일반적으로 시스코 IOS 12 버전이라면 8MB 정도의 메모리가 필요하다.
라우터는 외부 인터넷이나 원거리에 있는 지점간 통신을 하기 위해 통신 포트를 제공한다. 일반적으로 2개를 제공하는 시리얼 포트는 첫번째 포트가 serial0, 두번째 포트는 serial1로 지정돼 있다.
PC 의 COM 포트는 일반적으로 비동기 방식의 포트(Async Port)에 해당하는 반면, 시스코 라우터의 시리얼 포트는 동기(Synchronous) 방식이다. 또한 라우터에도 이더넷 포트가 있어서 스위치나 허브를 연결할 수 있다. 그밖에도 라우터에는 콘솔(console) 포트와 AUX(AUXiliary) 포트가 있는데, 이는 라우터를 처음 설치하거나 유지보수를 위해 설정을 변경할 때 사용한다.

라우터의 핵심 : 라우팅 테이블
스위치가 MAC 어드레스를 기반으로 패킷을 목적지로 전달하는 것처럼, 라우터도 어드레스 테이블에 해당하는 '라우팅 테이블'을 가지고 라우팅 서비스를 제공한다. 이 라우팅 테이블에 기록된 정보를 바탕으로 라우터는 자신에게 보내온 패킷을 어디로 전달할 것인지 결정한다. 보다 정확하게 말하면, 라우터는 철저하게 라우팅 테이블에 의존해 라우팅을 한다. 따라서 라우터의 운영은 라우팅 테이블을 관리하는 것이 절반 이상의 비중을 차지하며, 이 라우팅 테이블을 어떻게 구성하고 관리하느냐에 따라 라우터의 원래 목적, 즉 최적의 경로를 찾는 것이 가능해진다.
라우팅 테이블의 정보를 관리하는 방법은 크게 정적(static) 라우팅과 동적(dynamic) 라우팅으로 나눌 수 있다. 정적 라우팅은 관리자가 직접 라우터에 대해 접속하려는 특정 장소, 즉 상대 라우터를 지정하는 방식이며, 동적 라우팅은 라우터가 자체적으로 라우터끼리의 접속 정보를 주고받아 라우팅 테이블이 자동 갱신되는 방법이다.
동적 라우팅이 당연히 편하고 효과저인 방법처럼 보이지만, 정적 라우팅도 라우터 자체의 부하가 적고 회선 대역폭의 효율이 좋다는 장점이 있다. 때문에 모뎀이나 브로드밴드 네트워크와 같이 필요할 때만 연결하는 환경에서는 라우팅 정보를 라우터끼리 주고받지 않는 정적 라우팅이 주로 이용된다.
동 적 라우팅은 자동으로 라우팅 테이블이 갱신된다는 장점으로 인해 장애가 발생된 라우터가 라우팅 정보에세 제거됨으로써 네트워크 장애의 영향을 피할 수 있으며, 일부 라우터가 사라지거나 새로이 추가돼도 항상 최적의 경로로 데이터를 전송할 수 있다. 이미 헤아릴 수 없을 정도로 많은 라우터가 설치돼 있는 인터넷은 정적 라우팅을 적용하기에는 이미 너무 복잡한 상태라고 할 수 있다.

최적 경로 찾기의 조건 : 라우팅 프로토콜과 라우팅 알고리즘
그렇다면 동적 라우팅 테이블은 어떤 방식으로 만들어지는 것일까. 연결된 라우터끼리 무작위로 정보를 전송해 이를 저장하는 방식으로는 복잡 다단한 구성을 갖고 있는 인터넷에서 라우터가 최적의 경로를 찾을 수 없을 것이다.
이렇게 라우터끼리 서로의 정보를 주고 받는 방식을 정한 것이 바로 라우팅 프로토콜이며, 이들 라우팅 프로토콜은 일정한 라우팅 알고리즘을 바탕으로 이뤄져 있다. 라우팅 알고리즘은 거리 계산 방식(Distance Vector Advertisement)과 연결 상태 방식(Link State Advertusement)으로 나눠지며, 거리 계산 방식의 라우팅 프로토콜에는 RIP, IGRP, EIGRP가, 연결 상태 방식 라우팅 프로토콜에는 OSPF, IS-IS, NLSP 등이 대표적이다.
거리 계산 방식은 네트워크 어드레스에 대해 거리(홉 수)와 방향(라우터의 어느 포트인지) 정보를 다른 라우터로 보내 라우팅 테이블 정보를 변경하는 방법이다. 반면 연결 상태 방식은 여기에 더해 대역폭, 전송지연, 회선 신뢰도, 부하 등을 적절히 조합해 최적의 경로를 선택한다. 다시 말해 라우터를 여러 개 거쳐서 홉 수가 많더라도 회선 속도가 보다 빠른 쪽으로 경로를 설정할 수 있다는 것이다.

· RIP
RIP는 처음에 제록스의 XNS(Xerox Network System)에서 사용하기 위한 라우팅 프로토콜로 개발됐다. 이후 1982년에 BSD(Berkeley Standard Distribution) 버전 유닉스의 TCP/IP 프로토콜 환경에서 ‘routed’라는 프로세스 형태로 구현되면서 일반에 널리 알려졌으며, RFC(Request For Comment) 1085로 제정, 인터넷 표준 라우팅 프로토콜로 정해졌다.
RIP는 초기에 빠른 속도로 인터넷 환경에 적용됐는데, 그 이유는 당시의 인터넷은 그다지 복잡하지 않았기 때문에 RIP와 같이 구현이 쉽고 견고한 라우팅 프로토콜을 원하고 있었기 때문이다.
RIP에서는 송신지와 수신지 간의 거리를 패킷이 경유하는 라우터의 개수에 해당하는 홉(hop) 수로 표시하는데, 하나의 라우터를 경유한다면 이는 1홉의 거리가 되며, 2개의 라우터를 경유한다면 2홉의 거리가 되는 것이다.
RIP는 매 30초 이내에 새로운 라우팅 정보를 발송하며, 만약 180초 이내에 새로운 라우팅 정보가 수신되지 않으면 해당 경로를 이상 상태로 간주한다. RIP에서는 액티브와 패시브 두 가지 유형의 사용자를 정의하고 있다.
액 티브 사용자(라우터가 대표적임)는 자신이 속해 있는 네트워크 내에서 데이터그램 패킷을 통해 매 30초마다 라우팅 정보를 브로드캐스트한다. 반면에, 패시브 사용자(호스트 컴퓨터가 대표적임)는 RIP 정보를 수신해 경로를 갱신하지만, 스스로 라우팅 정보를 송신하지는 않는다. RIP 패킷 내에는 송신지에서 바라본 각 수신지 주소와 홉 수 등이 포함돼 있다.
그러나 RIP에는 몇가지 결함이 있다. 홉 수가 15를 넘는 대규모 네트워크에는 적합하지 않고, 서브넷 마스크를 지원하지 않으므로 IP 주소 영역의 활용을 제한한다. 또한 경로 테이블 전체를 매 30초마다 전송하므로 네트워크 대역폭의 효율적인 사용이 어렵고 최적의 경로를 찾기 위한 정보로 홉(거리값)만을 고려하므로 RIP가 선택한 경로가 최적의 경로가 아닌 경우가 발생할 수 있다. 이후 RIP의 단점을 보완하기 위한 RIP v2가 개발되긴 했지만, 다른 라우팅 프로토콜과의 경쟁에서 밀려, 그다지 많이 사용되지는 않고 있다.

· OSPF
1980년대 중반 이후 RIP 프로토콜의 한계가 드러나자 IETF( Internet Engineering Task Force)는 SPF(Shortest Path First) 알고리즘에 기반한 IP 네트워크용 라우팅 알고리즘인 OSPF를 개발했다.
OSPF는 ‘Open Shortest Path First’란 이름에서 알 수 있듯이 모든 사양이 개방돼 있다. OSPF의 사양은 RFC 1247(후에 RFC 1583; OSPF v2로 대체)로 발표됐다.
OSPF 는 연결 상태(link state) 개념을 기반으로 한다. 논리적인 영역 내의 모든 라우터는 연결 상태 정보를 모든 라우터에 전송하는데, 이로 인해 논리적인 그룹 영역의 모든 라우터에 일관된 연결 상태 정보 데이터베이스가 제공된다.
각 라우터는 이를 통해 SPF(Shortest Path First) 알고리즘을 실행해 경로를 계산하고 이것을 라우팅 경로로 간주한다. 이는 RIP와 달리 연결 실패가 감지된 후 1초 이내에 재연결하는 기능을 제공한다. 업데이트된 라우팅 정보만을 생성하기 때문에 네트워크 트래픽도 적으며, 논리적인 네트워크 체계에서 계층을 형성하고, 확장성이 좋다.
OSPF는 라우터간에 변경된 최소한의 부분만을 교환하므로 네트워크의 효율 저하를 최소화하며, 라우터의 위치를 설정함에 의해 확장성과 대규모 네트워크에 적용할 수 있는 장점이 있다. OSPF는 RIP가 갖고 있는 여러 단점을 해결할 수 있지만, 프로토콜 자체가 복잡해 구성과 관리가 어렵다는 것이 단점으로 지적된다.

· IGRP
IGRP(Interior Gateway Routing Protocol)는 시스코에서 독자적으로 개발한 프로토콜이다. RIP와 유사하게 홉 수를 기준으로 정보를 전송하는 IGRP는 회선의 전송 능력, 전송 지연 시간, 회선의 사용율, 신뢰성을 바탕으로 라우팅 경로를 결정한다. IGRP는 또한 복수 경로에서의 로드밸런싱 기능을 지원한다.

· OSI 라우팅
OSI 참조 모델을 만든 ISO(International Organization for Standardization)가 OSI 참조 모델의 네트워크 계층 프로토콜을 위한 라우팅 프로토콜로 개발했다. OSI 라우팅의 기반이 되는 IS-IS는 처음에 DECnet에서 사용되는 라우팅 개념에서 출발했다. 초기에는 OSI 표준 모델의 네트워크 계층 프로토콜인 CLNP(Connectionless Network Protocol)를 위한 라우팅만을 지원했으나, 후에 IP 네트워크를 위한 버전도 개발됐다.
OSI 라우팅 프로토콜은 OSI 참조 모델에 근거한 표준 라우팅 프로토콜이기는 하지만, 실제 환경에서는 잘 사용되지 않는다.

2007년 11월 11일 일요일

CSE에 cisco/MS Technet/KTword World 추가

Google Custom Search에 Cisco와 MS Technet을 추가하였다.
위의 검색창에 검색어를 넣어 검색한 후 결과창에서 cisco.com이나 MS Technet 라벨을 선택하면 된
cisco.com에는 Network에 대해 공부를 하면서 꼭 알아야 할 내용들에 대한 문서화가 잘 되어있고
http와 함께 pdf로 다운로드도 제공된다. 마찬가지로 MS Technet에서도 방대한 양의 기술문서들을
찾아볼 수 있다.

정보통신용어들에 대한 광범위한 검색과 해설이 제공되고 있는 KTword World도 추가하였다.

[Related Postings]
2007/09/07 - [Miscellaneous] - [QAOS.com] 구글 Custom Search Engine의 활용
2007/09/14 - [Whole Category] - Google CSE & AdSense
2007/10/14 - [Miscellaneous] - [Tip] Google CSE를 이용해 블로그 내부검색하기

2007년 11월 8일 목요일

[scrap] Link Level Flow and Error Control

[Source] William Stallings - High-Speed Networks : TCP/IP and ATM Design Principles
[Selective Translation] FINAL LAB of Korea University

1 The need for flow and error control

1.1. Flow Control

destination이 source에서 보내는 PDU(Protocol Data Unit)흐름을 조절할 수 있도록 해주는 protocol mechanism.

-Flow Control의 필요성:

destination은 수신 PDU를 처리하는데 시간 소비. -SRC에서 DST가 처리할 수 있는 것보다 많은 양의 PDU를 보내는 경우.
destination protocol entity는 higher layer protocol user로 수신 data를 보내기 위해 data를 buffering. - 만일 User가 Data 처리가 늦다면 Buffer는 가득찰 것이고 따라서 DST는 SRC의 Data를 제한하거나 순간적으로 정지시켜야 한다.
destination은 수신 data를 network상의 다른 node로 보내기 위해 buffering. - DST가 Data를 다른 I/O Port로 재전송할 경우 In/Out을 일치시키기 위해 Incoming flow를 제한.

1.1.1 Hop Scope

Intermediate system간의 flow control은 link level에서 구현된다.

1.1.2 Network Interface

flow control은 link level 및 network protocol에서도 구현될 수 있다.

link level에서 구현: LAPB In X.25
network layer에서 구현: ATM, Frame-Relay.

1.1.3 Entry to Exit

logical connection상에서 entry와 exit node 간의 flow control이 구현될 수 있다.

1.1.4 End to End

end system간의 link level 및 logical connection 상에서 flow control을 구현할 수 있다.

1.2. Error Control

source와 destination간에 전송된 PDU의 loss및 damage를 복구.

FCS(Frame Check Sequence)를 통한 Error Detect 포함.

2. Link Control Mechanisms

link level에서 쓰이는 error 및 flow control의 세가지 방식으로 stop and wait, Go-Back-N, selective reject가 있다. 일반적으로 data를 전송할 때 single block 보다는 block을 여러 frame으로 조각내어 보내는데 이유는 다음과 같다.

수신측 buffer size의 제한.
전송시간이 길 경우 error 발생확률이 높다. - Frame이 짧으므로 error 검출이 빠르고 재전송되는 Data의 양도 작다.
LAN과 같은 Shared Medium에서 하나의 station이 전송매체를 사용하는 시간이 길어짐.

2.1. Stop and Wait

flow control의 가장 간단한 방법이며 source는 destination으로부터 ACK frame을 받은 후에 다음 frame을 보내는 방식이다.
- 두가지 형태의 에러:

destination이 error가 있는 frame을 받거나 frame소실.
- SRC: Error Detect and Discard Frame.
- DST: ACK를 받을때까지 Data를 저장하고 만일 ACK가 오지 않는다면 Frame을 재전송한다.
전송한 ACK frame의 손상.
- 0과 1로만 구별된 frame number.
- stop and wait ARQ 그림 9.3
- propagation time이 transmission time보다 클 경우 link 이용률 감소.

2.2. Sliding window Techniques

- 한번에 여러 개의 frame을 보냄으로써 link 이용률을 증가시키는 방법.

frame을 저장할 수 있는 buffer수가 stop and wait보다 많아 ACK의 수신을 기다릴
필요 없이 frame을 전송.
number field가 k-bits field인 경우 frame을 modulo 로 번호을 매긴다.
frame을 보내면 window가 줄어들고 ACK를 받으면 window가 늘어남.
그림 9.5 sliding window depiction
그림 9.6 Example of sliding window protocol

2.2.1 Go-back-N ARQ

sliding window에 기반을 두고 일반적으로 가장 널리 쓰이는 error control.
source는 최대 허용치까지 frame을 전송하고 destination은 error가 발생하지 않은 경우 RR(receive ready) frame을 전송. Error가 발생할 경우 REJ frame을 전송
error가 발생하면 destination은 error frame이 제대로 된 frame이 되어 수신 될 때 까지 error frame 이후에 들어오는 frame 들을 제거.
REJ를 받은 source는 error frame및 error frame이후에 전송한 모든 frame을 재전송한다.

- Go-Back-N 에서 발생될 수 있는 상황들.

Damaged frame
- i번째 frame에서 error가 발생할 경우 -> REJ i를 보낸다.
- 전송도중 i번째 frame이 소실되고 destination이 i+1번째 frame 을 받을 경우 -> REJ i를 보낸다.
- i번째 frame이 전송도중 소실되고 source가 추가적인 frame을 보내지 않을 경우 -> B에서는 아무것도 받지 않은 상태 -> A에서는 time-out 상태 -> A에서 RR Frame을 보낸다.
Damaged RR
- destination이 i번째 frame을 받고 i+1번째 RR을 보냈는데 전송도중 소실 될 경우.(timer 작동중)
- source timer가 만료된 경우.
Damaged REJ

2.2.2 Selective-reject ARQ

negative acknowledgement(SREJ)를 받은 frame만을 재전송.
destination은 go-back-n 방식보다 buffer수가 많다.
frame retransmission을 최소화

3. ARQ Performance

3.1. Stop and Wait ARQ

3.1.1 Error-free Stop-and-Wait

3.1.2 Stop-and-wait ARQ with Errors

3.2. The Parameter a

3.3. Stop-and-Wait Revisited

3.4. Sliding-window ARQ

3.4.1 Error-free Sliding-window Flow Control

3.4.2 Selective-reject ARQ

3.4.3 Go-back-N ARQ

[Related Articles]
2007/11/08 - [Network] - [scrap] TCP/IP Sliding Window

Daejun University, Computer Networks Lab
Data Communications 강의자료 Chapter 10 Data Link Control[ppt]

William Stallings - Data and Computer Communications 7th Edition
Chapter 7 Data Link Control Protocols[ppt:partly translated]

William Stallings - Data and Computer Communications
Chapter 7 Data Link Control[ppt:partly translated]

Behrouz A. Forouzan - Data Communications and Networking 4th Edition
Chapter 11 Data Link Control[ppt:partly translated]

[scrap] TCP/IP Sliding Window

[Source] Secure.pe.kr 강의실

TCP/IP Sliding Window

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "window"라고 부르는 Buffer를 이용한다. window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정 중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다.
반대로 안정적인 네트워크 상황 하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징 중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다.
이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로서 "Sliding Window" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding window"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

[그림 1]
TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다.
하나는 보내기 위한 window, 또 다른 하나는 받기 위한 window이다.

[그림 2]
호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다.
상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

[그림 2]의 "A"컴퓨터가 "B"컴퓨터에게 10kbyte size의 데이터를 전송하려 한다고 가정을 해 보자.
또, 이 컴퓨터의 "window size"는 8k이고, "TCP segment size"는 1k라고 가정을 한다.
사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다.
"TCP segment size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜 "TCP segment size"라고 부른다.
예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서
먼저 10k크기의 데이터를 1k크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다.
TCP는 1k로 나눈 데이터마다 순서를 붙이게 된다.
1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다.
1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다.
마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다.
생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다.
만일 회선상의 문제가 있어서 ACK신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다.
이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "window Size"라고 부르는 것이다.

[그림 3]
[그림 3]처럼 호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 window size만큼 데이터를 전송하기 시작한다.
위의 예제에서 window size는 8K이다.
1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다.
그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다.
단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다.
성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.
이것이 "TCP Sliding Window"라는 기법이다.
window size만큼 데이터를 전송하고, 상대방으로부터 ACK신호가 올 때까지 기다렸다가 ACK신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다.
1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 ACK신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다.
우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

[그림 4]
일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 ACK신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다.
다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 ACK신호가 오지 않더라도 일단 그 전의 데이터에 대한 ACK가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.
[그림 4]에서 보면 window가 이동한 그림을 볼 수 있다.
예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 ACK신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다.
추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 ACK신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다.
적어도 2개 이상의 연속된 패킷이 들어왔을 때 ACK신호를 전송하도록 한 것이 그것이다.

[그림 5]
[그림 5]에서처럼 1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자.
그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 ACK신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.

[그림 6]에서 보면, 받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, ACK신호를 전송하고 있다.

[그림 6]
송신컴퓨터는 이렇게 수신컴퓨터의 ACK신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다.
만일 무슨 이유에선지 ACK신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까?
이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 ACK신호가 도착하지 않으면 재전송을 하기 위한 배려이다.

[그림 7]
결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다.
여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

[Related Articles]
2007/09/28 - [Network/Link for Network] - [Link] TCP/IP의 이해(IP Address & Subnet)

위키백과 - 슬라이딩 윈도우

Wikipedia - Sliding Window Protocol

2007년 11월 6일 화요일

나의 노트북 이야기

다음 달이면 산 지 2년이 되는 Laptop이다.

Asus A6Va--Q00VA (view larger image)

Specifications:

Intel Pentium M processor 740 1.73GHz
HD 80 GB
15.4" (WXGA) Colour Shine
128Mb ATI Mobility Radeon X700
Optical Drive 8x DVD-RW Dual
1024Mb DDR2 533MHz (512x2)
Wireless IEEE 802.11b/g
4x USB 2.0, 1xIEEE 1394
Video Camera built-in (1.3 million pixels) and Microphone
Built in Bluetooth
Weight: 2.85kg

RAM은 원래 512Mb이 들어있던 것을 1024Mb로 늘렸다.
작년 말에 비디오칩 고장으로 한달여 AS를 다녀온 것 말고는 항상 나의 곁을 지켜주었다.
Harddisk가 좀 작은 편이라거나, Graphic Driver의 호환성이 그다지 좋지 않다라든지 하는
자잘한 불만이 있기는 하지만 대부분의 해외 Review에서 볼 수 있듯이 상당히 "solid"한 제품이다.
1030 Euro 정도 줬는데 지금이야 그 돈이면 훨씬 더 좋은 물건을 살 수 있지만 당시 이만한 물건을
이 정도 가격에 구한 것은 최선의 선택이었다고 할 수 있다.

이 노트북에서 사용한 운영체제들은 처음에 설치되어 온 Windows XP Home,
나중에 새로이 설치한 Windows XP Pro, Windows FLP, Windows Vista Business와
OpenSuSE Linux 10.1, 10.2, 10.3, Kubuntu 7.04 등이 있다.
지금은 Windows XP Pro와 OpenSuSE 10.3을 Multibooting으로 사용하고 있다.

소음에 민간한 나에게 그다지 소음에 대해 자주 신경쓰도록 하지는 않지만
Windows 상에서는 Fan이 비교적 자주 돌고, 일단 Fan이 도는 소리는 좀 거슬리는 편이다.
일예로 아마 Office 2007이 워낙 자원을 많이 사용하는 편이라서 그럴 거라 생각하지만
MS Word를 사용할 때 Fan이 자주 돌면 꽤나 신경이 쓰인다.
CPU 온도도 60도 이상에서 노는 일이 잦다.

반면에 Linux에서는 훨씬 쾌적하게 느낀다. 현재 CPU 온도는 50도이다.
온도가 낮게 유지되니 당연히 Fan도 자주 돌지 않는다.

그런데 Laptop에서 Linux를 Main Operating System으로 사용하지 못하게끔 하는 몇 가지 문제가 있었다.
그 중 첫째는 Synaptics Touchpad가 Linux에서 너무 민감하게 반응하여 사용에 큰 불편이 있을 지경인데
설정도구가 없다는(사실은 있지만 제대로 작동되지 않는) 점과
Headphone을 잭에 꽂으면 소리가 전혀 나지 않는다는 점이었다.
근래 도서관에서 강의파일들을 열어봐야 할 일이 많은 데 이 문제로 인해 도서관에서는 Linux를 사용할 수 없었다.
과거형으로 적었는데 그 이유는 이 두 문제가 최근에 모두 해결되었기 때문이다.

Touchpad문제는 새로운 OpenSuSE 10.3을 설치함으로써 자연스레 해결되었고, Headphone문제는 어제 오늘
양일 간에 걸친 삽질 끝에 마침내 해결을 보았다.
원래는 나중을 위해 이 삽질기를 기록해 둘 요량으로 적은 글이 사설이 길어져 이렇게 잡담코너로 넘어와 버렸다.

이젠 Bootloader의 Default OS를 Linux로 바꿔야 할 때가 드디어 온 것 같다.

[Tip][OpenSuSE10.3] Samba Configuration on KDE

KDE환경에서 Samba Server 설정하기 + SWAT

GSAMBAD와 같은 Samba Server를 위한 Frontend도 이미 나와 있기도 하고,
앞서 2007/06/05 - [Linux] - SAMBA 설정과 이용에서 언급했듯이 여러가지 방법이 존재한다.
(물론 어떠한 방법이든 내부에서 최종적으로 하는 일은 동일하다.)

여기서 보이려는 방법은 나의 경우에서 가장 간편하다고 생각된 방법이다.

1. Menu에서 Personal Settings를 선택한다.

2. Internet & Network를 선택한다.

3. 아래 쪽의 Samba를 선택한다.

4. Samba Server의 설정을 변경하려면 Administrator Mode를 선택해주어야 한다.

5. root password를 입력하고 계속한다.

6. Base Settings 항목이 나타난다. 원하는 대로 설정을 변경하고 apply를 누르면 적용된다.
또한 여기에서 보안레벨을 정하게 되는 데 각자 환경에 따라 적절한 것을 선택한다.
나의 경우 가장 일반적인 보안정책으로 생각되는 User를 선택하였다. (이렇게 하면 Samba Server에 접속하는
이용자는 Server에 등록된 id와 password를 입력해야만 접속할 수 있다.)

7. Shares항목에서는 공유되고 있는 목록을 보여준다. 목록의 기존공유를 편집하거나 새 공유 추가, 공유제거 등
의 작업을 할 수 있다.

8. Samba를 사용할 사용자를 등록한다.

9. DOS charset을 CP949로 바꾸어 주었다.(CP949는 euc-kr을 포함하는 MS의 확장완성형 문자 인코딩)

10. 부팅시 Samba를 기동시키기 위하여 Runlevel을 수정한다.

11. smb와 nmb service가 활성화되어야 한다.

12. SWAT는 xinetd를 통해 구동되게 된다.

만약 Firewall이 기동되어 있다면 Samba Server를 위한 Port를 열어 주어야 한다.
위 그림에 보이는 Samba Server 항목(이 안에서 여기서 설명하고 있는 대부분의 과정을 설정할 수도 있다.)에
들어가면 Firewall Settings에서 Port 열어주도록 할 수 있다.
또한 여기의 Service Start항목을 통하여 10과 11의 과정을 간단하게 설정할 수도 있다.

13. swat service를 활성화 시킨다.

14. SWAT가 구동되면 웹브라우저에 http://localhost:901이라 입력하여 불러올 수 있다.
(User Name과 Password를 물어오는 데 기본적으로는 root로 login한다.)

15. SWAT에 접속한 화면이다.

16. GLOBALS 항목에서 앞서 설정했던 내용들을 볼 수 있다. 물론 여기에서 새로이 설정할 수도 있다.
기왕에 SWAT을 사용할 거라면 위에서 설명한 3~9까지의 과정은 이곳에서 설정해도 된다.
다만 아주 간단한 설정을 위해서라면 SWAT가 필요하지 않을 수도 있을 것이다.

17. Username/Password를 등록한다. (다른 컴퓨터에서 이 Samba Server에 접속할 때 사용할 정보이다.)

18. Samba Server가 service되고 있는 상태를 볼 수 있다.
설정 변경 후 여기에서 smbd/nmbd를 재시작 해줄 수 있다.

19. 동일한 네트워크에 위치하고 있는 Windows에서 네트워크 환경에 들어가면 아래와 같이
Samba Server에 의해 공유되고 있는 자원을 볼 수 있다.
실제로 사용하려면 17에서 설정한 정보를 사용하면 된다.

꼭 이렇게 하지 않아도 GUI환경에서 Samba Server를 필요에 맞게 설정할 수 있는 방법은 여러가지가 있다.
편리한 것을 선택하는 것은 사용자의 몫이다. SWAT만으로도 Samba Server설정에 관한 모든 것을 할 수 있다.
그러나 기본적으로 설정파일을 수정하고 console에서 필요한 service들을 구동시키는 작업을 한 번쯤은 해보고
GUI도구를 사용할 것을 권하고 싶다. 설정파일 안에 있는 내용들을 전혀 이해하지 못하는 상태에서 GUI도구가
제공해주는 편리한 기능을 제대로 사용할 수가 없기 때문이다.

[Related Article] 2007/06/05 - [Linux] - SAMBA 설정과 이용

[Tip] SAMBA 설정과 이용

SAMBA는 Windows와 Linux간의 상호 파일과 Print 시스템을 공유하는 것을 가능하게 해 준다.
Linux만으로 구성된 Network을 보는 것은 아주 드문 일이므로
이 기종 간의 Networking(Linux Server의 Resource를 Windows Client에서 사용이 가능하도록 해주고,
그 반대로도 마찬가지.)을 가능하게 해주는 SAMBA의 가치는 아주 높다고 할 수 있다.

Linux에서 대부분의 Service들은 기본적으로 Terminal에서 설정파일을 편집하고,
필요한 Command를 내려주는 방법으로 설정이 가능하다.
또한 한 편으로 이러한 작업을 손쉽게 해주는 GUI Tool들이 존재한다.
두 가지 방법 중 편리하다고 느끼는 쪽을 선택할 수 있는 것이다.

SAMBA의 경우는 하나의 가능성이 더 있는데, 바로 SAMBA Package에 포함되어 있는
SWAT(SAMBA Web Administration Tool)를 이용하는 방법이다.
SWAT을 통해 SAMBA의 모든 것을 Web-Interface에서 설정, 관리할 수 있다.
SWAT는 localhost의 tcp 901 port로 구동된다. 웹브라우저로 불러와 사용하면 된다.
각 설정 항목마다 HELP Link가 있어서 확인해가며 설정해나갈 수 있다.
Samba konfigurieren mit SWAT
삼바(TM) 설치 및 활용 가이드 열번째 판 A2

삼바 서버를 위해 구동되는 Daemon은 다음의 둘이다.
smbd (SMB Daemon)
nmbd (Client를 위해 NetBIOS nameserver를 지원)

inetd에 의해 Daemon을 실행시키기 위해 (이미 들어있지 않다면) 아래 내용들을
/etc/inetd.conf 에 추가시켜야 한다.

# SAMBA NetBIOS services (for PC file and print sharing)

netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd

netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd

이렇게 하면 시스템 시작 시 SAMBA Server가 구동된다.

Server환경은 설정 파일인 /etc/samba/smb.conf파일을 통해서 수정한다.

smb.conf example from KLDP

more..

수정을 마치고 나서는 Service를 재시작해야 변경사항이 적용된다.

# /etc/init.d/smb restart

2007년 11월 3일 토요일

Kaffeine과 Xine에서 한글자막 보기

Xine은 /usr/share/xine/libxine1/fonts에 들어있는 자신만의 font를 사용하므로 원하는 font를 사용하려면

TrueTypeFont를 XineFont로 바꾸어 주는 변환 프로그램인 xine-fontconv가 필요하다.

xinehq.de에 가서 xine-lib-x.x.x.tar.bz2를 받는다.(여기서 사용한 것은 1.1.8 버전이다.)

$ tar xvfj xine-lib-1.1.8.tar.bz2 // 압축해제

$ cd xine-lib-1.1.8/misc // xine-fontconv.c 가 있는 위치로 이동

$ sudo gcc xine-fontconv.c -o xine-fontconv `freetype-config --cflags --libs` -lz

[주의] ' 나 " 가 아니라 `이다. 위의 명령을 복사하여 붙여넣으면 가장 확실하다.

freetype2 libraries가 시스템에 설치되어 있어야 한다.

이렇게 하면 xine-fontconv가 생성된다.

이제 원하는 TrueTypeFont(gulim.ttf or Eunjin.ttf)를 /usr/share/xine/libxine1/fonts로 복사한다.

OpenSuSE의 경우 설치해둔 TrueTypeFont들은 /usr/share/fonts/truetype에서 찾을 수 있다.

xine-fontconv도 마찬가지로 복사하고 /usr/share/xine/libxine1/fonts로 이동한 다음

은진폰트로 예를 들면
# ./xine-fontconv Eunjin.ttf Eunjin euc-kr // euc-kr Encoding으로 Eunjin이란 XineFont 생성

Eunjin.tar.bz2

이제 카페인을 실행시키고
Settings-> xine Engine Parameters -> subtitles 선택 후 Beginner Options 에서
subtitle size를 large 정도로 변경해 준다.
그리고 encoding of the subtitles를 euc-kr로 바꾼다.

Expert Options 탭으로 이동해서 sans 라고 되어 있는 부분을 Eunjin이라고 바꿔준다.

이것으로 설정완료.

(주의.) 처음 이 Tip을 작성할 당시는 아무런 문제가 없었지만 그 후 몇 차례 Kaffeine의 update가 있었다.
아마도 그 이후로 한글자막이 정상적으로 보여지지 않고 있다. 한글이 모두 #######로 나오는 문제이다.
새로이 xine font를 생성해 보았고 다른 글꼴들도 시도해 보았지만 모두 마찬가지였다.
최신 버젼의 Kaffeine에게 일종의 Bug가 있는 것이 아닐까 추측하고 있을 뿐이다.
Mplayer를 사용하면 여전히 한글자막이 잘 보여진다.

최근의 업데이트 이후에는 정반대의 현상이 벌어지고 있다.
Mplayer에서는 한글자막이 표시되지 않고, Kaffeine에서는 잘 나온다.
역시나 버전에 따라 Bug가 서로 다르게 나타나는 것으로 보인다.
한동안 SMplayer만 썼더니 Kaffeine이 어색하다.

===================================================================

<Xine 한글 자막 설정>

Xine에서 한글 자막을 보려면 설정 파일을 직접 수정해야한다.

설정 파일은 ~/.xine/config

굵은 글씨로 써진 부분을 수정하면 된다.

# subtitle size
# { tiny small normal large very large huge }, default: 1
subtitles.separate.subtitle_size:large

# subtitle vertical offset
# numeric, default: 0
#subtitles.separate.vertical_offset:0

# font for subtitles
# string, default: sans
subtitles.separate.font:Eunjin

# encoding of the subtitles
# string, default: euc-kr
subtitles.separate.src_encoding:euc-kr