요약

  • RFC 1013에 적힌 X11 연결에서 첫 바이트는 8진수 102, 곧 대문자 B이거나 8진수 154, 소문자 l이었다. 전자는 높은 자리 바이트부터, 후자는 낮은 자리 바이트부터 보낸다는 뜻이며 보통 16비트·32비트 프로토콜 값은 클라이언트가 택한 순서를 따른다.
  • 비트맵과 픽스맵 데이터는 서버가 알리는 이미지 형식을 따른다. 보통 필드에 필요한 바이트 교환은 서버가 맡고, 이미지의 원래 순서가 다르면 클라이언트가 서버 형식에 맞춰 바이트를 바꾼다.

한 작업용 컴퓨터의 프로그램이 다른 컴퓨터에 연결된 화면에 창을 띄우려 한다. 크기, 자원 번호, 그리기 명령을 보낸다. 두 컴퓨터가 여러 바이트로 된 숫자를 반대 순서로 저장하면 같은 바이트 묶음을 다른 너비로 읽을 수 있다. 전선은 바이트를 잘 운반했을 뿐, 어느 쪽이 숫자의 앞인지 알려 주지 않는다. X11은 첫 바이트에서 그 일을 끝내려 했다.

1987년 6월 나온 RFC 1013은 X 프로토콜 11판의 알파 업데이트를 담았다. 원격 클라이언트는 신뢰할 수 있는 바이트 흐름을 쓸 수 있고, TCP라면 번호 N인 화면의 서버가 6000+N번 포트에서 연결을 받는다. 클라이언트는 먼저 16비트와 32비트 값을 어떤 순서로 읽을지 알린다. 문서의 102와 154는 8진수다. 각각 ASCII 대문자 B와 소문자 l이며, 높은 자리부터 또는 낮은 자리부터라는 신호다. 첫 글자부터 양쪽의 번역 업무가 정해진다.

보통 프로토콜 필드에서는 클라이언트의 선택이 기준이다. 서버는 자기 기계의 순서가 다르면 바이트를 바꾸고, 응답에 담긴 여러 바이트 값도 특별한 예외가 없는 한 그 선택에 맞춘다. 응용 프로그램은 화면을 가진 컴퓨터가 숫자를 메모리에 어떻게 놓는지 알아낼 필요가 없다. 서버가 이 차이를 흡수한다. 작은 B나 l은 인사말보다 업무 지시서에 가깝다.

그런데 이미지가 오면 담당이 바뀐다. 비트맵과 픽스맵은 서버가 지정한 형식으로 주고받는다. 연결 설정 응답에서 서버는 image-byte-order, 비트맵 주사선 단위와 채움, 지원하는 픽스맵 형식을 알린다. XYFormat에서는 주사선의 각 단위에, ZFormat에서는 픽셀 값마다 이미지 바이트 순서가 적용된다. 클라이언트의 원래 이미지 순서가 서버와 다르면 클라이언트가 바이트를 바꿔야 한다. 그림을 보여 줄 컴퓨터가 그림의 포장법을 정한다.

이 이중 규칙은 구현자가 놓치기 쉬운 구체적 지점을 만든다. 창 크기를 정확히 보내고 자원 번호도 잘 읽으면서, 그림 바이트에만 명령의 규칙을 잘못 적용할 수 있다. RFC의 두 규칙에서 바로 보이는 가능성이다. 당시 화면이 실제로 일그러졌다는 사건을 지어낼 필요는 없다. 명령이 읽혔다는 사실은 그다음 픽셀의 준비 상태까지 보증하지 않는다.

첫 바이트 뒤에는 클라이언트가 기대하는 프로토콜 버전과 인가 방식의 이름·데이터가 따라간다. 서버는 자기가 지원하는 버전과 연결 결과를 돌려주고, 받아들이면 자원과 이미지 형식을 설명한다. 유효한 인가 방식의 세부 목록은 이 핵심 문서에서 정하지 않았다. 여기서 중요한 것은 순서다. 첫 글자가 명령의 읽는 법을 정하고 서버의 답이 이미지의 만드는 법을 정한다.

누가 정답인 바이트 순서를 가졌는지 겨루는 이야기가 아니다. 서버는 클라이언트의 숫자 문법을 읽고, 클라이언트는 서버의 픽셀 문법으로 그림을 꾸린다. X11은 서로 다른 컴퓨터를 같은 몸으로 바꾸지 않았다. 대신 누가 어느 부분을 번역할지 적어 두었다. 한 창에 그림을 띄우기 전에 먼저 끝내야 했던 일이다.