TODO:
커스텀 이모티콘 (?? 원래 피진-네톤에 없던 기능)
쪽지 기능이나 채팅 기능은 현재 정상동작한다. 대화에 초대되어 응답하는 부분만 제대로 하니까, 여기선 프로토콜의 변화가 없어서(?) 잘 작동하더군.
이제 원래 고치고 싶었던 것인 파일전송 부분이다.
서로 파일 보내기 요청은 할 수 있다 -_-;; 파일이 실제로 오가지 않아서 문제지만!
일단 파일 받는 부분부터 해보지. 아니, 거절 당하는 것조차 제대로 안 된다. 흐음... 오는 파일 요청 거절하는 것 부터 하겠음 흐음.
(2011-02-17 13:23:30) <-- [ Chat ] {WHSP 0 xxx@nate.com|dpc_07405:18878|NDhA FILE REQUEST%091%09b_09.jpg|382315|1:2147483647:139|6415f5b00e9de9576ca0b0911e15a8a6}
(2011-02-17 13:23:31) <-- PING 0(2011-02-17 13:23:31) --> PING 189
(2011-02-17 13:23:32) --> [ Chat ] {WHSP 2 xxx@nate.com FILE NACK%091%09b_09.jpg|382315|1:2147483647:139|6415f5b00e9de9576ca0b0911e15a8a6}
(2011-02-17 13:23:32) <-- CTOC 0 xxx@nate.com dpc_07405:18878|NDhA 56MAIL 1 xxx@nate.com FILE CANCEL 1 1:2147483647:139!(2011-02-17 13:23:32) <-- [ Chat ] {WHSP 2}
상대방이 파일을 보내겠다고 하면 저렇게 거절하는 것이다. 일단 보내겠다고 상대방이 신청한 것의 형식은...
ChatView::slotSendFileList
다시 여기로 왔군. (네톤 소스코드).
일단 [1,999] 구간에 포함되는 정수를 두 개 생성한다. 각각 j와 l이라 부른다.
WHSP 0
xxx@nate.com|dpc_07405:18878|NDhA (전과 다르게 DP key가 붙은 모양)
FILE REQUEST 보내겠다
%09 1 1개 보내겠다
이하 각 파일별로 반복.
%09 b_09.jpg 파일명이다(공백은%20으로 바뀐 버전으로)
|382315 파일 크기
|1:2147483647:139 sRandom이라는 부분. j++:myCMN:l 으로 이루어짐. 파일의 쿠키로 사용됨.
|6415f5b00e9de9576ca0b0911e15a8a6 ??? 윈도우 네톤은 이걸 보내는데, 피진네톤은 안 보낸다. 그냥 무시하지뭐.
피진에서 파일을 받는 부분의 코드는 whsp_cmd 에 구현되어 있다. 이미 파일을 여러개 받을 수 있는 처리는 되어있다 (내가 제작자가 아니다보니 몰랐다 -_-).
일단 예전 프로토콜과 다르게 dpkey가 id에 붙어서 오기 때문에, 이를 처리하는 코드를 넣어주었더니 파일 수신이 놀랍게도 된다. 그리고 상대방이 파일을 보내려다가, 수락하기도 전에 취소하는 경우 취소도 잘 된다.
다만, 파일전송이 완료되었다는 신호를 구 프로토콜로 보내서 네톤이 이해 못 하는듯. 그보다도 파일 취소 신호나 제대로 보내는걸 일단은 해봐야겠군.
nateon_xfer_request_denied
여기서 거절 신호를 생성해 보낼 것 같다. 아마도. 아니네!;; 설마 처리하는 코드가 없는건가?
static voidnateon_xfer_cancel_recv(PurpleXfer *xfer){purple_debug_info("nateon", "%s\n", __FUNCTION__);/* FIXME: send FILE NACK */
/* free NateonXfer */nateon_xfer_end(xfer);}
그렇다... -_-;;; 원작자도 아마 귀찮았을 것이다.
nateon_xfer_request_denied
이 함수도 아무 처리 안 되어있음.s
WHSP 2 xxx@nate.com FILE NACK%091%09b_09.jpg|382315|1:2147483647:139|6415f5b00e9de9576ca0b0911e15a8a6
이게 만들어야 하는 신호. 거절하고 싶은 파일에 대한 정보를 목록으로 보내주면 될 것이다. 아마. 따로따로 파일별로 취소할 수 있나?! 는 잘 모르겠는데.
WHSP 0 xxx@nate.com|dpc_04903:8994|NDhA FILE NACK%091%09yr|2714|266:10009502162:427
윈도우 네톤과 리눅스 네톤으로 실험해본 결과 거절은 한번에 한 파일씩 하기 때문에 피진과 호환성에서 문제될 게 없을 듯 하다.
리눅스용 네톤엔 좀 문제가 있는데, 좀 사투리를 구사하고 있다는 점이다. -_-;;; 자기가 NACK 명령을 보낼때는 dpkey를 안 보내고, 받을때는 잘 인식한다. 혹은 받을때 NACK이 없어도 잘 인식한다. 골때리게 하는군. 뭐 나도 리눅스 네톤이 하는대로 일단 하지 뭐.
내가 보내는 파일을 상대가 거절할 경우, 이쪽에서 거절을 인식 못하더라. 왜냐... who가 이상하게 저장되는 듯... 아, 내 잘못이구나. -_-;;
파일 전송이 안 되는건 아니니까 파일전송 완료 메시지가 되게 해보자... 쉽게 고쳤고.
피진에서 네톤으로 파일을 보내는 것은 조금 더 어렵다. -_-;; 보내는걸 네톤에서 거절하는 경우도 처리가 안 되어있군. 리눅스용 피진에 버그가 있군. 그냥 스트링이 꼬인거... 내가 수락할까말까인데 상대방의 수락을 기다린단 말이 뜬다 -_-;;
으음. 아까 되던게 안 되는 느낌인데;; 내 실수일 확률이 크다. 이미 있는 코드를 refactor한답시고 여기저기 건드렸거든... 내 실수는 아니고 좀 잘못 구현되어 있었는듯.
생각보다 원작의 파일 보내기/받기가 완벽하게 구현되어 있지 않구나...;;
어쨌든 내가 보내는걸 상대방이 거절할 경우도 처리 했다.
상대방이 파일을 보내다가 끊는 경우를 처리해보자. 이미 잘 되는군. 이어받기따윈 안 된다. 아마 피진 자체가 지원 안 해서 그럴 것 같은데 어차피 내 입장에서 그다지 구현하고 싶은 매력은 없음.
네톤 -> 피진 으로 보내다 네톤에서 취소: 잘 됨.
네톤 -> 피진 으로 보내다 피진에서 취소: 안 됨.
피진에서 취소하는 경우는 그런 경우엔 이게 모범답안.
sss가 ccc에게 파일을 보내는 장면이다.
(2011-02-17 20:31:39) <-- [ Chat ] {JOIN 0 ccc@nate.com 데헷 홍길동 3.0 1}(2011-02-17 20:31:39) --> [ Chat ] {WHSP 12 ccc@nate.com FILE REQUEST%091%09openSUSE-KDE4-LiveCD-Build0339-x86_64.iso|722468864|723:10009502162:75}(2011-02-17 20:31:39) <-- [ Chat ] {WHSP 12}
(2011-02-17 20:31:44) <-- [ Chat ] {WHSP 0 ccc@nate.com|dpc_10605:15962|NDhA FILE ACK%091%09723:10009502162:75}
(2011-02-17 20:31:44) <-- CTOC 0 ccc@nate.com dpc_10605:15962|NDhA 46REQC NEW 192.168.0.40:5004 10026452103:12733(2011-02-17 20:31:44) --> CTOC 201 ccc@nate.com N dpc_10605:15962|NDhA 46REQC RES 192.168.0.50:5004 10026452103:12733
(2011-02-17 20:31:44) --> [ P2P_B ]-{ATHC 0 sss@nate.com ccc@nate.com 10026452103:12733 6004 0}-(2011-02-17 20:31:44) <-- [ P2P_B ]-{ATHC 0 100 0}-(2011-02-17 20:31:44) <-- [ P2P_B ]-{FILE 0 ACCEPT 723:10009502162:75 0}-(2011-02-17 20:31:44) --> [ P2P_B ]-{FILE 0 INFO FILENAME 722468864 CHAT 0}-(2011-02-17 20:31:44) <-- [ P2P_B ]-{FILE 1 START 0 0}-(2011-02-17 20:31:44) --> [ P2P W ]-{FILE 1 DATA 8192}-(2011-02-17 20:31:44) <-- PNAK 201(2011-02-17 20:31:44) --> [ P2P W ]-{FILE 2 DATA 8192}-(2011-02-17 20:31:44) --> [ P2P W ]-{FILE 3 DATA 8192}-(2011-02-17 20:31:54) --> PONG 0(2011-02-17 20:31:54) <-- PONG 0
여기까진 전송 시작. 아래부터 취소.
(2011-02-17 20:31:57) <-- [ Chat ] {WHSP 0 ccc@nate.com|dpc_10605:15962|NDhA FILE CANCEL%091%09723:10009502162:75}(2011-02-17 20:31:57) --> [ Chat ] {WHSP 13 ccc@nate.com FILE CANCEL%091%09723:10009502162:75}(2011-02-17 20:31:57) <-- [ Chat ] {WHSP 13}
애초에 구현이 안 되어있었다 -_-;; 간단히 구현 되더군.
이제 다시 보내기를 처리해야겠군. 보내기가 제일 어려울듯... 이라고 생각했지만, 잘 생각해보면. 파일 수신은 "그냥" 된거나 마찬가지니까 어쩌면 보내기도 조금만 고치면 "그냥" 될지도 모른다.
WHSP 0 sss@nate.com|dpc_01004:28059|bwzc FILE ACK%091%09894:10026452103:605
피진이 이걸 처리 못하더군. 그리고 FILE명령어의 에러처리 부분으로 들어간 것으로 보아서는 그냥 프토토콜이 살짝 변경되어 그런걸수도... 예전에는 REQC라는 명령어가 confirm정도에 해당했는듯도하다.
ssss에게 파일을 보내는 모습.
(2011-02-17 21:40:09) <-- [ Chat ] {WHSP 0 cccc@nate.com|dpc_10303:2051|NDhA FILE REQUEST%091%092011-02-16.txt|3766|3:2147483647:163|5bf2ea40444ea698c35e9df4d8e737fd}(2011-02-17 21:40:11) --> [ Chat ] {WHSP 11 cccc@nate.com FILE ACK%091%093:2147483647:163}(2011-02-17 21:40:11) --> CTOC 112 cccc@nate.com N dpc_10303:2051NDhA 49REQC NEW 192.168.0.50:5004 10009502162:17502611(2011-02-17 21:40:11) <-- [ Chat ] {WHSP 11}(2011-02-17 21:40:11) <-- PNAK 112(2011-02-17 21:40:11) <-- CTOC 0 cccc@nate.com dpc_10303:2051|NDhA 49REQC RES 192.168.0.40:5004 10009502162:17502611=(2011-02-17 21:40:11) --> [ P2P_B ]-{ATHC 0 ssss@nate.com cccc@nate.com 10009502162:17502611 6004 0}-(2011-02-17 21:40:11) <-- [ P2P_B ]-{ATHC 0 100 0}-(2011-02-17 21:40:11) --> [ P2P_B ]-{FILE 0 ACCEPT 1 0}-
흐음. 이게 모범적인 대화인데 흐음; 도통 이해가 안 된다.
사실 피진->네톤 뿐 아니라 윈도그네톤->네톤 으로 파일 전송도 안 된다. 내 탓이 아닌지도 모르겠군...;; 서로 다른 IP를 쓰는 경우엔 잘 되나?
과연... 피진에서 네톤으로 파일 보내기도 잘 되는군. 수신 취소테스트를 해보겠다. 보낼때, 받는 쪽에서 취소하는 경우 잘 취소됨. 하지만 이쪽에서 보내다 취소하는 경우는 안 됨. 역시 사소한 프로토콜 차이일 것이다... 그냥 구현이 안 된거였다 -_-;; 내가 좀 전에 한 구현을 그냥 call함으로서 해결. 이제 안 되는거 없는 거 같은데 좀 테스트기간을 두면 되겠군.