dev.haz3.com

개발하자~

Skip to content


NateOn - 네이트온 프로토콜 플러그인 프로젝트

※ 리눅스 네이트온 파일전송 정리 문서 (2008년 3월 21일) : 리눅스 네이트온 - 파일전송

P2P 관련 개발 가지 수

  1. 파일 보내기
    1. 내 서버에 접속 후 진행
    2. 상대 서버에 접속 후 진행
    3. FR(File Relay) 서버에 접속 후 진행
  2. 파일 받기
    1. 내 서버에 접속 후 진행
    2. 상대 서버에 접속 후 진행
    3. FR(File Relay) 서버에 접속 후 진행

0. 용어정의

  • File Cookie
    • 대화세션에서 파일전송을 위해 보내는 쪽에서 생성하는 유일한 키값
    • 혼용 용어 : SS Cookie, FileTransfer? Cookie
    • 만드는 형식 : "[INDEX]:[MyCMN]:[RANDOM_NUMBER]"
  • P2P Cookie
    • DP세션에서 파일전송 네고를 위해서 사용하는 유일한 키값.
    • 파일 받는쪽에서 REQC NEW를 보낼때 만들어서 보냄.
    • 혼용 용어 : DP Cookie
    • 만드는 형식 : "[My CMN]:[rand()+(cnt++)]"

1. 파일 보내기

2. 파일 받기

DP Session

>>> 1. 대화요청 받음. <<<

  • CTOC (서버 => 나) 
    CTOC [TID] [Sender ID] [MSG LEN]\r\n
INVT [Sender ID] [SS IP] [5004] [SS Cookie]
    • MSE LEN : "\r\n" 없음.
    • 예: 
      CTOC 0 sender@nate.com 72
INVT sender@nate.com 192.200.200.203 5004 31FB2ECF558D28A36C4F031386E4A

SS Session

  • ENTR (나 => 서버) 
    ENTR [TID] [My ID] [NICK] [SS Cookie] [UTF8] [P]\r\n
  • USER (서버 => 나) 
    USER 0 [IDX] [COUNT] [Sender ID] [NICK] [NAME]\r\n
    • IDX : 이미 접속한 사용자들의 인덱스 (0에서 시작).
    • COUNT : 전체 접속 사용자 수
  • ENTR (서버 => 나) 
    ENTR 1\r\n

>>> 2. 파일 정보 받음 <<<

  • WHSP (서버 => 나) 
    WHSP 0 [Sender ID] FILE REQUEST%09[FILE COUNT]%09[FILE NAME]|[FILE SIZE]|[FILE Cookie]\r\n
    • FILE COUNT : 보내는 파일 개수
    • 여러파일 보내기 예제 : REQUEST%092%09file01.txt|100|1:111:111%09file02.txt|200|2:222:222\r\n

DP Session

>>> 3. P2P 정보 교환 <<<

  • CTOC (나 => 서버) 
    CTOC [TID] [Sender ID] N [MSG LEN]\r\n
REQC NEW [My P2P IP]:[My P2P Port] [My P2P Cookie]\r\n
    • MSE LEN : "\r\n" 2byte 포함한 메시지 길이
  • PNAK (서버 => 나) 
    PNAK [TID]\r\n
  • CTOC (서버 => 나) 
    CTOC 0 [Sender ID] [MSG LEN]\r\n
REQC RES [Sender P2P IP]:[Sender P2P Port] [Sender P2P Cookie]\r\n

P2P Session

>>> 4. P2P 서버 접속 핸드쉐이크 <<< 

아이디어 :
P2P 서버는 나와 상대 모두 열고 있습니다.
서로 경쟁적으로 상대 서버에 접속을 하고 먼저 접속하는 사람이 ATHC를 보냅니다.

여기서 중요 포인트는 상대서버로 접속한 쪽이 접속 후 ATHC를 보낸다는 사실입니다.
다시말해서, ATHC를 보내는 규칙은 보내고, 받고가 아니고, 접속했느냐? 접속을 받았느냐? 입니다.

실제상황 :
보통은 REQC NEW 를 보내는 쪽(파일을 받는 쪽)이 자신의 서버 IP와 Port를 알려주기 때문에
REQC RES를 보내는 쪽(파일을 보내는 쪽) 보다 빨리 ATHC를 받습니다.
  • ATHC 보낼때 
    ATHC 0 [My ID] [Your ID] [P2P Cookie] 6004 0\r\n
  • ATHC 받았을때 응답 
    ATHC 0 100 6004 0\r\n

>>> 5. 파일 전송 수락 <<<

  • FILE ACCEPT (나 => 파일보내는 상대) 
    FILE 0 ACCEPT [FILE Cookie] 0\r\n

>>> 6. 파일 전송 핸드쉐이크 <<<

  • FILE INFO (파일보내는 상대 => 나) 
    FILE 0 INFO FILENAME [FILE SIZE] CHAT 0\r\n
  • FILE START (나 => 파일보내는 상대) 
    FILE 0 START [FILE OPSET] 0\r\n
    • FILE OPSET : 이어받기 기능. (처음부터 받으려면 0)

>>> 7. 파일 전송 <<<

  • FILE DATA (파일보내는 상대 => 나) 
    FILE [COUNT] DATA [DATA LEN]\r\n
[DATA DUMP]
    • COUNT : 1부터 시작.
    • DATA LEN : 8191 정도.
    • DATA DUMP : "DATA LEN" 만큼 binary로 붙여서 보냄.

>>> 8. 파일 전송 끝 <<<

  • FILE END (나 => 파일보내는 상대) 
    FILE [TID] END N 0\r\n
    • 파일 받은 byte와 보낼때 파일 크기를 비교 다 받으면 FILE END를 받는 쪽에서 보내는 쪽에 보냄.

3. FR 경유 파일전송

※ 윈도즈 강제 FR 경유, 레지스터리 변경, 받는쪽에서 강제 FR 경유 사용가능.
HKCU\Software\SK Communications\Messenger\Network
"force use FR = Y" 없으면 추가.

3.1 파일 받기

3.1.1 리눅스에서 파일 받기

리눅스 <-- Chat Session
WHSP 0 ring0320@nate.com FILE REQUEST%091%09ChangeLog.txt|304640|1:2147483647:46

리눅스 --> DP Session
CTOC 10 ring0320@nate.com N 51
REQC NEW 124.136.189.153:5004 902126197:192441888
리눅스 <-- DP Session
PNAK 10

리눅스 <-- DP Session
CTOC 0 ring0320@nate.com 47
REQC RES 192.168.0.1:5004 902126197:192441888

리눅스 <-- DP Session
CTOC 0 ring0320@nate.com 46
REQC RFR 10.19.0.79:5004 902126197:192441888

# 윈도즈에서 취소 

리눅스 <-- Chat Session
WHSP 0 ring0320@nate.com FILE CANCEL%091%091:2147483647:46

3.1.2 윈도즈 파일 보내기

윈도즈 <-- DP Session
CTOC 0 ring0320@lycos.co.kr 51
REQC NEW 124.136.189.153:5004 902126197:192441888

윈도즈 --> DP Session
CTOC 138 ring0320@lycos.co.kr N 47
REQC RES 192.168.0.1:5004 902126197:192441888
윈도즈 <-- DP Session
PNAK 138

윈도즈 --> DP Session
CTOC 140 ring0320@lycos.co.kr U 46
REQC RFR 10.19.0.79:5004 902126197:192441888

3.2 파일 보내기

3.2.1 리눅스에서 파일 보내기

리눅스 --> Chat Session
WHSP 4 ring0320@nate.com FILE REQUEST%091%091201674348330.png|42187|426:902126197:27

리눅스 <-- DP Session
CTOC 0 ring0320@nate.com 41
REQC NEW 192.168.0.1:0 10014827278:6301

리눅스 --> DP Session
CTOC 26 ring0320@nate.com N 48
REQC RES 124.136.189.153:5004 10014827278:6301

리눅스 <-- DP Session
CTOC 0 ring0320@nate.com 57
REQC FR 211.234.239.175:5004 10014827278:6301 406378858

# 윈도즈에서 취소 

리눅스 <-- Chat Session
WHSP 0 ring0320@nate.com FILE CANCEL%091%09426:902126197:27

3.2.2 윈도즈에서 모니터링

윈도즈 --> DP Session
CTOC 742 ring0320@lycos.co.kr N 41\r\n
REQC NEW 192.168.0.1:0 10014827278:6301\r\n

윈도즈 <-- DP Session
CTOC 0 ring0320@lycos.co.kr 48\r\n
REQC RES 124.136.189.153:5004 10014827278:6301\r\n

윈도즈 --> DP Session
REFR 743 ring0320@lycos.co.kr\r\n

윈도즈 <-- DP Session
REFR 743 211.234.239.175 5004 406378858\r\n

윈도즈 --> FR Session
FRIN 0 ring0320@lycos.co.kr 406378858\r\n

윈도즈 <-- FR Session
FRIN 0 100\r\n

윈도즈 --> DP Session
CTOC 744 ring0320@lycos.co.kr N 57\r\n
REQC FR 211.234.239.175:5004 1 10014827278:6301 406378858\r\n

※ 정리

  1. 프로토콜 제작시 상대편 ID를 포함해서 Command를 만든다. => 받는 사람 역시 DP서버에서 상대편 ID로 바꿔져서 도착한다.
  2. 파일 보내는 쪽에서는 RFR을 보낸다.
  3. 파일 받는 쪽에서 DP서버에 FR서버 정보를 얻는다. ( REFR명령 ) => 보내는 쪽에서는 REFR명령을 하지 않음. => REQC RES 를 받고 P2P접속 시도 후 에러가 발생하면 REFR 명령을 함.
  4. DP Session에서는 메시지가 변형된다. => Chat, P2P Session은 보낸 메시지가 그대로 전달된다. => 특히 P2P Session은 서버를 거치지 않기 때문에 변형이 없이 그대로 보인다.
  5. P2P 접속 상태에서 Socket 접속이 정상적으로 되면 다음 접속 프로세스가 이뤄지지 않도록 해야함. => 프로세스 상 여러번 접속시도가 있는데 매번 접속시도 시 접속이 이뤄졌는지 확인 후 접속 시도 하도록해야 함.
Powered by Trac 0.10.4
By Edgewall Software.