이번의 telnet bbs 를 작업하면서.. 정말 빡셌던건 정작 telnet client 였습니다.

일단 저는 linux desktop 을 사용합니다. linux desktop 에서는 3가지 정도의 telnet client 선택지가 있었습니다.

1. gnome-terminal 에서 사용하는 netkit-telnet 의 telnet client

2. linux 용 putty

3. winows 용 putty 를 wine 으로 사용하기

1번은... 7bit 시대에 만들어진 client 라서 자꾸 multibyte 를 힘들게 합니다. 입력한 내용을 전송할때부터 문자가 깨져서 전송됩니다...

2번은 한글 입력기가 안붙습니다..(어?)

3번은.. 될줄 알았는데 여전히 한글 입력기가 안붙습니다..(어?)

어제 새벽에 마지막 퍼즐(?)인 modem 접속을 telnet 접속으로 바꿔주는 녀석을 작업하다가 telnet client 쪽 procotol 을 구현하다보니.. 어? 그냥 이정도면 telnet client 하나 만들 수 있는거 아니야? 라는 생각이 들더라구요.

그래서 작업이 어느정도 되고나서 필요한 코드를 fork 한다음 otelnet 이라는 telnet client 를 별도로 만들어습니다.

client 를 만들면서.. 제가 고생했던게 떠오르더라구요. 그래서 DEBUG mode 를 두고 서버와 데이터를 주고받는 내용을 hex 값으로 저장하는 기능을 새로 넣었습니다. (제가 하나요? AI 가 하죠 ㅋㅋㅋ)

이렇게 해서 otelnet 을 디버깅하고 있었는데.. 뭔가 자꾸 문자가 깨지는겁니다. 원인을 분석하다보니 pge4telnet 의 서버쪽에서 client 로부터 받는 데이터를 일부 잘못처리하는 경우가 있는거같더라구요. 서버에도 log 는 찍히니까...

* otelnet 의 화면

* otelnet 의 log

* pge4telnet 서버의 log

이렇게 3개를 조합하니까 어디에 문제가 있는지 구간 파악을 하기가 상대적으로 명확했습니다. 결국 이것 덕분에 서버의 채팅모드에서 있던 버그를 하나 잡았네요.(글쓰기 모드에 있던 버그도 잡힌건 덤입니다 ㅋㅋㅋ)

다음은 이런식으로 조합되고 출력된 정보를, 서버코드를 수정하는 claude code 에게 지시내린 내용입니다. 여튼 저는 이런식으로 AI 와 작업하고 있습니다 :D

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

* 서버는 OUTPUT_LOCALE="EUC-JP" 로 운영되고 있습니다.

* client 는 EUC-JP 로 데이터를 전송하고 있습니다.

client 의 코드는 문제가 없으며, 모든 구간을 확인했을때 서버에서 telnet line mode 에서 데이터를 수신할때 다음의 문제가 있을 수 있습니다.

* filter_iac_bytes_only() 함수가 0xF3 바이트를 잘못 제거하고 있습니다.

* 텔넷 IAC 명령은 항상 0xFF로 시작해야 하며, 0xF3 단독은 일반 데이터입니다.

* BINARY 모드에서는 0xF3을 포함한 모든 바이트(0x00-0xFF)가 투명하게 전송되어야 합니다. (0xFF만 0xFF 0xFF로 escape)

서버의 level6 코드에서 EUC-KR, EUC-JP, UTF-8 등의 경우에서 모두 이상이 없을지에 대해 위의 내용을 참고해서 검토를 진행해주세요. 모든 경우를 다 pass 할 수 없다면 "OUTPUT_LOCALE" 값을 기준으로 동작해도 됩니다.

level6 작업을 하면서 filter_iac_bytes_only() 함수에서 telnet line mode 용으로 filter_iac_linemode() 를 새로 생성했습니다. 이 상황을 기준해서 level5 에 관련된 개선내용을 적용해야 할지를 분석해주세요.