출처 : http://superkkt.com/138

오늘은 바이트 오더에 대해서 정리를 해보자. 책을 찾아보면 이해가 되었다가 한참후에 생각해보면 항상 햇갈리는 부분이라서 따로 정리를 해본다.

바이트 오더에는 리틀엔디안과 빅엔디안 두가지가 있다. PC에서 일반적으로 사용하는 Intel, Alpha 같은 CISC 계열 CPU는 리틀엔디안을 사용하고 SPARC, 모토로라 프로세서 같은 RISC 계열 CPU는 빅엔디안을 사용한다.

그럼 두가지 엔디안의 차이는 무엇일까? 차이점은 2바이트 이상의 데이터(정수형뿐만 아니라 일반대상체도 포함됨)를 메모리에 저장할때 어느 바이트부터 저장을 하는지이다. 리틀엔디안은 높은 번지(Most Significant Byte)에서 낮은 번지(Least Siginificant Byte)로 기록을 하고, 빅엔디안은 낮은 번지(LSB)에서 높은 번지(MSB)로 기록을 한다.

컴퓨터는 2진수를 사용해서 데이터를 메모리에 저장한다. C언어에서 사용하는 정수형(int)은 4바이트를 사용하는데 정수형 134480385 값은 아래와 같이 표현된다. 오른쪽 끝이 2^0 부분이고 왼쪽으로 갈수록 증가해서 왼쪽 끝이 2^31 이다. (2진수 값을 보기 편하게 하기위해 볼드 처리를 하고 134480385 같은 이상한 숫자를 사용했다)

위의 표현이 빅엔디안 시스템에서 메모리에 저장될때는 낮은 번지(LSB)에서부터 높은 번지(MSB)로 기록을 하기 때문에 아래와 같이 변경없이 그대로 저장이 된다.

하지만 리틀엔디안 시스템은 높은 번지(MSB)에서부터 낮은 번지(LSB)로 저장을 하기 때문에 아래와 같이 각 바이트의 순서가 뒤집어져서 저장이 된다. 오른쪽에서부터 왼쪽으로 데이터를 저장한다고 생각하면 이해하기 쉬울것이다.

!주의!
바이트를 구성하는 비트는 엔디안의 영향을 받지 않는다. 즉, 위에서 설명한대로 리틀엔디안 시스템에서 순서가 뒤집혀서 저장되는것은 2진수로 변환된 전체값을 반대로 뒤집는것이 아니라, 바이트 단위로 끊어서 뒤집어 저장하는 것이다.

그럼 두 엔디안의 차이에서 발생하는 문제가 무엇일까?

위에서 보여준 리틀 엔디안으로 저장된 134480385의 2진수 표현을 빅엔디안 방식으로 해석해보자. 빅엔디안은 낮은 번지부터 시작한다고 했으니 왼쪽에서 오른쪽으로 읽어나가면 되겠다. 그럼 1로 셋팅된 값이 각각 2^24, 2^17, 2^10, 2^3 자리에 있으니 10진수로 변환하면 16909320이 된다. 졸지에 134480385가 16909320로 변했다!!


두가지 방법에는 나름대로 장단점이 있다.

빅엔디안의 경우에는 사림이 보기에 매우 직관적이라는 장점이 있지만, 데이터 타입이 변경되어 4바이트에서 8바이트로 확장될때 메모리에서 전체 4바이트 값을 오른쪽으로 이동시켜야한다.

리틀엔디안은 사람이 보기에는 별로 직관적이지 않지만 데이터 타입 변경으로 메모리가 확장될때 단지 오른쪽에 새로운 바이트를 추가하기만 하면 된다.

그럼 이제 언제 엔디안의 차이가 문제를 발생시키는지 알아보자. 빅엔디안이던 리틀엔디안이던간에 그 컴퓨터에서 뭔짓을 하더라도 아무런 문제도 생기지 않는다. 하지만 요즘 세상에 혼자만 노는 컴퓨터가 있던가? 다들 다른 컴퓨터와 네트웍으로 연결되어서 통신을 한다. 바로 이때 문제가 발생한다. 리틀엔디안 컴퓨터가 512라는 숫자를 전송했는데 받는 컴퓨터는 빅엔디안이다. 그럼 빅엔디안 컴퓨터는 그 값을 131072로 해석하겠지.

이런 문제를 해결하기 위한 방법으로 네트웍 오더라는 개념이 있다. 모든 컴퓨터는 네트웍으로 정수형을 전달하기 전에 네트웍 오더로 변환 후에 전송해야 한다. 그리고 받는쪽은 네트웍 오더를 자신이 사용하는 바이트 오더로 변환 후에 그 값을 사용해야만 한다. C에서는 htons, htonl, ntohs, ntohl 같은 함수를 사용해서 변환을 한다. 참고로 네트웍 오더는 빅 엔디안이다. 그래서  솔라리스 스팍 버전에서 htons, htonl 함수는 비어있는 메크로이다.

바이트오더 문제를 해결하는 또 다른 방법은 숫자를 문자열로 전송하는 방법이다. 512라는 값을 전송할때 정수형 512로 전송하는게 아니라 문자열 512로 전송한다. 그리고 받는 쪽에서 문자열 512를 정수형으로 변환해서 사용하면 된다. 이 방법은 사용하기 편하다는 장점이 있지만 숫자를 표현하는데 정수형보다 더 많은 바이트를 사용해야하고 숫자 표현에 몇 바이트를 사용할지 송수신자 사이에 약속이 있어야 한다. 몇 바이트를 사용할지 고정하지 않는 경우에는 구분자를 사용해서 어디까지가 숫자를 표현하는 문자열인지 표시해야 한다.

아스키(ASCII) 코드 표

• ACE가 무엇인지 궁굼하신 분들에게 조금이나마 도움이 되었음 합니다.;
• 원문링크 : http://www.cs.wustl.edu/~schmidt/ACE-overview.html

1 ACE의 개요

ADAPTIVE Communication Environment(ACE)는 동시처리방식의(concurrent) 통신 소프트웨어의 많은 핵심 패턴들을 구현한, 공개로 배포되는 오픈소스기반의 객체지향 프레임워크이다. ACE는 크로스플렛폼 기반의 재사용가능한 C++ wrapper facade와 일반적인 통신 소프트웨어 주제 상에서 실행되는 프레임워크 요소들의 모음집이다. (역주 - wrapper facade는 기존의 API함수들이 존재하는 시스템일 경우 좀더 객체지향적으로 에러처리나 함수의 정리등을 해놓은 클래스 패턴을 말한다. Win32 API의 대표적인 wrapper facade는 MFC를 들 수있다.)

ACE에 의해 제공되는 통신 소프트웨어 기능들은 다음과 같다.

• 이벤트 디멀티플렉싱 (event demultiplexing)
• 이벤트 핸들러 디스페칭 (event handler dispatching)
• 시그널 핸들링 (signal handling)
• 서비스 초기화 (service initialization)
• 프로세스간 통신 (interprocess communication)
• 공유메모리 관리 (shared memory management)
• 메세지 라우팅 (message routing)
• 분산 서비스들에 대한 동적 (재)설정 (dynamic (re)configuration of distributed services)
• 동시실행과 동기화 (concurrent execution and synchronization)

ACE는 고성능 실시간 통신 서비스와 어플리케이션을 개발하는 데에 촛점이 맞추어져있다. 이것은 프로세스간 통신, 이벤트 디멀티플렉싱, 명시적 동적 링킹, 동시처리방식의 객체지향 네트워크 어플리케이션과 서비스의 개발을 단순화시켜준다. 추가적으로 ACE는 시스템 설정과 동적으로 연결된 서비스들에 의한 실시간 재설정, 프로세스와 쓰레드상에서 서비스들을 실행하는 것을 자동화해준다.

ACE는 계속 발전중이며 그 미래는 밝다. ACE는 상업적으로는Riverace를 통하여 오픈소스 비지니스 모델을 사용하여 지원되고 있다. 추가적으로 ACE 개발팀의 많은 맴버들이 The ACE ORB (TAO)를 구현하는데 현재까지 힘쓰고 있다.

2 ACE를 사용하는데 있어 잇점은?

ACE를 사용하면 얻을 수 있는 많은 잇점들중 몇가지는 다음과 같다.

• 이식성의 증가 - ACE 컴퍼넌트들은 하나의 운영체계상에서의 동시처리방식의 네트워크 어플리케이션들을 작성하기 쉽게 해주며, 수많은 다른 운영체계로 그것을 포팅하는 작업을 손쉽게 해준다. 게다가, ACE는 오픈소스이고 공짜이기 때문에 여러분은 특별한 운영체계나 컴파일러 설정에 제한받을 것을 우려할 필요도 없다.
• 소프트웨어 품질의 증가 - ACE 컴퍼넌트는 통신 소프트웨어의 핵심 품질요소(융통성, 확장성, 재사용성, 모듈화등등)들을 증진시키기 위해 많은 핵심 패턴을 사용해서 디자인되었다.
• 효율과 예측력(predictability)의 증가 - ACE는 넓은 분야의 어플리케이션 QoS 요구를 지원하기 위해 조심스럽게 디자인되었다. 이런 요구에는 딜레이에 민감한 어플리케이션을 위한 낮은 지연(latency), 대역폭에 민감한 어플리케이션을 위한 높은 성능, 실시간 어플리케이션을 위한 예측능력등이 있다.
• 높은 수준의 표준 미들웨어로써 일찌기 변화를 시도 -- ACE는 The ACE ORB (TAO)에서 사용된 재사용가능한 컴퍼넌트와 패턴들을 제공한다. TAO는 실시간 시스템과 고성능에 최적화된 CORBA의 오픈소스 표준을 따르는 구현물이다. 따라서, 협력적인 미들웨어 솔루션을 제공할 목적으로 ACE와 TAO는 서로 궁합이 잘맞도록 구현되어있다.

3 ACE의 구조 및 기능

다음 도해는 ACE의 핵심 컴퍼넌트와 그 종속관계를 그려놓은 것이다:

이 도해안에 있는 계층들의 구조와 관계들을 다음에 기술되어있다.

3.1 ACE OS 어뎁터 레이어

이 레이어는 직접적으로 C로 작성된 고유 운영체계 API들의 최상위에 존재한다. 이것은 "POSIX 호환" OS 어뎁터 계층을 제공한다. 이것의 역할은 다음과 같은 운영체계 API들과 관련된 플렛폼-의존적인 특성들로부터 ACE내의 다른 레이어와 컴퍼넌트들을 보호한다.

• 동시처리와 동기화 - 멀티쓰레딩, 멀티프로세싱, 동기화에 관련된 운영체계 API
• 프로세스간 통신(IPC)와 공유 메모리 - 지역(local)/원격(remote) IPC와 공유 메모리에 대한 운영체계 API
• 이벤트 디멀티플렉싱 체계 - 동기적/비동기적인 디멀티플렉싱 입출력, 타이머, 시그널, 동기화의 이벤트들을 위한 운영체계 API
• 명시적 동적 링킹 - 어플리케이션 서비스들이 설치시 혹은 실행시간에 재설정하는 것을 허락하는 기능
• 화일 시스템 구조 - 화일이나 디렉토리를 관리하기 위한 시스템 API

운영체계 어뎁테이션 계층의 이식성은 ACE로 하여금 상당수의 운영체계상에서 실행되는 것을 가능하게 한다. ACE가 포팅되고 테스트된 운영체계는 다음과 같다.

• 모든 Win32 운영체계 - 심지어는 WinCE도 가능. VC, C++ Builder, Visual Age에서 가능
• Mac OS X
• 거의 모든 UNIX 계열 운영체계 - Solaris, SGI IRIX, DG/UX, HP-UX, Tru64UNIX, AIX, DG/UX, UnixWare, SCO, Debian Linux, RedHat Linux, FreeBSD, NetBSD 등등
• 실시간 운영체제 - LynxOS, VxWorks, ChorusOS, QnX Neutrino, RTEMS, OS9, PSoS
• 기타 운영체제 - OpenVMS, MVS OpenEdition, CRAY UNICOS

이 모든 운영체제를 위해서 단일한 소스트리가 사용된다. ACE의 자바버젼도 또한 존재한다. ACE의 운영체계 어뎁테이션 계층에 의해 제공되는 추상화 덕택에, 이 모든 플렛폼에서 단하나의 소스트리가 사용된다. 이 디자인은 ACE의 관리와 이식을 엄청나게 단순화 시킨다.

3.2 운영체계 인터페이스를 위한 C++ Wrapper Facade

ACE의 운영체계 어뎁테이션 계층덕분에 이식가능한 C++ 어플리케이션을 개발하는 것이 가능하다는 것을 보았다. 어쨌거나, 대부분의 ACE 프로그래머들은 위 도해에 나타나있는 C++ wrapper facade 계층을 사용한다. ACE C++ wrapper facade들은 내장 운영체계의 동시처리, 통신, 메모리관리, 이벤트 디멀티플렉싱, 동적 링킹, 화일시스템 API들을 개선하고 추상화시킨 안전한 C++ 인터페이스를 제공함으로써 소프트웨어 개발을 단순화 시킨다. 어플리케이션은 다음에 나열한 컴퍼넌트들을 선택적으로 상속받거나 조합하거나 인스턴스화하는 것에 의해 이 wrapper들을 결합하거나 조립할수 있다:

• 동시처리(Concurrency), 동기화(synchronization) 컴퍼넌트 - ACE abstracts native OS multi-threading and multi-processing mechanisms like mutexes and semaphores to create higher-level OO concurrency abstractions like Active Objects and Polymorphic Futures.
• IPC and filesystem components -- The ACE C++ wrappers encapsulate local and/or remote IPC mechanisms, such as sockets, TLI, UNIX FIFOs and STREAM pipes, and Win32 Named Pipes. In addition, the ACE C++ wrappers encapsulate the OS filesystem APIs.
• Memory management components -- The ACE memory management components provide a flexible and extensible abstraction for managing dynamic allocation and deallocation of interprocess shared memory and intraprocess heap memory.

C++ wrapper들은 운영체계 어뎁테이션 계층에서와 동일한 많은 기능들을 제공한다. 그러므로, 이 구성요소들은 독립적인 C 함수보다는 C++ 클래스와 객체의 입장에서 구축되어졌다. 이런 객체지향적 패키징은 ACE를 정확하게 사용하고 배우는데 필요한 노력을 감소시키도록 도와준다. 예를 들어 C++ wrapper들은 강한 타입성향을 가지기 때문에 C++의 사용은 어플리케이션의 내구성을 증가시킨다. 그 결과 컴파일러는 실시간에서 보다는 컴파일 타임때 타입 시스템 오류를 감지하는 것이 가능하다. 대조적으로 C 레벨운영체계 API에서는 실행하기 전까지는 타입 시스템 오류를 감지하는 것이 불가능하다. (소켓이나 화일시스템 I/O)

수행상의 과부하를 최소화하거나 제거하기위한 많은 테크닉을 채택하고 있다. 예를 들어, ACE는 메서드 호출 과부하를 제거하기 위해 광범위하게 C++ inline을 사용한다. 실행상의 중요한 wrapper들(소켓의 send/recv등등)에는 가상 메소드의 사용을 피하는 것도 한 예이다.

3.3 프레임워크

ACE는 저수준의 C++ wrapper facade들을 개선하고 통합하는 또한 보다 높은 레벨의 네트워크 프로그래밍 프레임워크를 가지고 있다. 이 프레임워크는 동시처리방식의 분산된 서비스의 동적 환경 설정을 어플리케이션에게 제공한다. ACE의 프레임워크 부분은 다음 컴퍼넌트들을 담고 있다 :

• 이벤트 디멀티플렉싱 컴퍼넌트 - ACE의 Reactor와 Proactor는 확장가능한, 객체지향 디멀티플렉서들이다. 이들은 I/O기반, 시그널기반, 동기화 객체 기반의 다양한 형태의 응답에 대응하는 어플리케이션에서 정의한 핸들러들을 디스패칭한다.
• 서비스 초기화 컴퍼넌트 - ACE의 Acceptor와 Connector 컴퍼넌트들은 한번 초기화가 끝난 통신 서비스가 실행하는 어플리케이션 고유의 처리 업무들로부터 능동적인/수동적인 초기화 역할을 담고 있다.
• 서비스 설정(configuration) 컴퍼넌트 - The ACE Service Configurator는 초기화때/실행중에 동적으로 결합된 서비스들의 설정기능을 제공한다.
• 계층체제의 스트림 컴퍼넌트 - The ACE Streams components은 계층형 서비스들로 구성된 유저레벨 프로토콜 스택과 같은 통신 소프트웨어 어플리케이션의 개발을 단순화시킨다.
• ORB adapter components -- ACE can be integrated seamlessly with single-threaded and multi-threaded CORBA implementations via its ORB adapters.

ACE 프레임워크 컴퍼넌트들은 수정하거나 재컴파일, 재링크, 게다가 종종 재시작을 하는 일 없이, 확장하거나 수정될 통신 소프트웨어의 개발작업을 수월하게 만들어준다. 이런 융통성은 ACE와 다음에 열거한 요소들과 결합되어 얻어지는 것이다.

• C++ 언어 기능들(템플릿, 상속, 동적 바인딩)
• 디자인 패턴(추상화 팩토리, 전략, 서비스 설정자등등)
• OS 기능 (동적 링킹, 멀티쓰레딩등등)

3.4 분산 서비스들과 구성요소들

In addition to its OS adaptation layer, C++ wrapper facades, and framework components, ACE provides a standard library of distributed services that are packaged as self-contained components. Although these service components are not strictly part of the ACE framework library, these service components play two roles in ACE:

• Factoring out reusable distributed application building blocks -- These service components provide reusable implementations of common distributed application tasks such as naming, event routing, logging, time synchronization, and network locking.
• Demonstrating common use-cases of ACE components -- The distributed services also demonstrate how ACE components like Reactors, Service Configurators, Acceptors and Connectors, Active Objects, and IPC wrappers can be used effectively to develop flexible, efficient, and reliable communication software.

3.5 상위레벨 분산컴퓨팅 미들웨어 컴퍼넌트

광범위하고 확장가능하며 효율적인 통신 어플리케이션을 개발하는 것은 ACE와 같은 통신 프레임워크를 사용한다 할지라도 도전적인 분야이다. 특별하게도, 개발자들은 아직 이와 같은 여러개의 복잡한 운영체계와 통신 개념을 마스터해야만 한다:

• 네트워크 주소체계와 서비스 식별(identification)
• 제시된 변환들(presentation conversions) - 암호화, 압축, 네트워크 바이트 정렬 변환등등
• 프로세스와 쓰레드의 생성 및 동기화.
• 원격 IPC(interprocess communication)를 인터페이스하는 함수 및 라이브러리 루틴.

상위 레벨의 분산컴퓨팅 미들웨어(CORBA, DCOM, 자바 RMI)을 채용함으로써 통신 어플리케이션 개발의 복잡함을 다소 경감시키는 것이 가능하다. 상위레벨의 분산된 컴퓨팅 미들웨어는 클라이언트와 서버사이에 위치하며, 분산 어플리케이션 개발에 있어서 많은 지루하고 에러가 나기 쉬운 측면을 자동화 시켜주고, 다음 특성들을 포함한다:

• 인증(authentication), 공증(authorization), 데이타 보안.
• 서비스 배치 및 바인딩.
• 서비스 등록 및 활성화(activation).
• 이벤트에 응답하기위한 디멀티플렉싱 및 디스패칭.
• TCP와 같은 바이트스트림 기반의 통신 프로토콜보다 상위의 메세지 프레임을 구현하기.
• 네트워크 바이트 정렬 및 인자 마샬링과 관계된 presentation conversion.

통신 소프트웨어 개발자들에게 이런 기능들을 제공하기 위해서, ACE 릴리즈에 다음 상위레벨 미들웨어 어플리케이션들이 번들로 포함되어있다:

• ACE ORB (TAO) -- TAO 는 ACE에 의해 구현된 프레임워크 컴퍼넌트와 패턴을 사용하여 구축된 CORBA의 실시간 구현물이다. TAO는 네트워크 인터페이스, OS, 통신 프로토콜, CORBA 미들웨어 컴퍼넌트 및 특징들을 담고 있다. TAO는 표준 OMG CORBA 레퍼런스 모델에 기초하여 구현되었으며, 고성능 실시간 어플리케이션을 위해 전통적인 ORB들의 결점을 보완하기위해 디자인된 개선점들을 가지고 있다. TAO는 ACE와 마찬가지로 오픈 소스 소프트웨어이며 완전히 공개이다.
• JAWS -- JAWS는 ACE에 의해 구현된 프레임워크 컴퍼넌트와 패턴을 사용하여 구축된 고성능의 adaptive 웹서버이다. JAWS는 프레임워크들의 프레임워크로써 구성되어있다. 전반적인 JAWS 프레임워크는 다음 컴퍼넌트과 프레임워크들을 가지고 있다.
  • Event Dispatcher
  • Concurrency Strategy
  • I/O Strategy
  • Protocol Pipeline
  • Protocol Handlers
  • Cached Virtual Filesystem

  각 프레임워크들은 ACE안에서 조합되고 확장됨으로써 구현된 상호협동적인 객체들의 집합으로서 구성되어있다. JAWS도 또한 오픈 소스 소프트웨어이며 완전히 공개이다.

출처 :

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=17&MAEULNo=8&no=43810&ref=43810