삶이란 긴 이야기 - SungMin

이제 남은건? 클라이언트가 되겠다.

물론 서버도 완성된건 아니지만 테스트 할 수 있는 여건은 다 된것일지라.



이런식으로 클라이언트 프로젝트를 하나 더 추가시키고

폼은.



대략 이렇게 만들자.. 버튼은 예제니까.. 계속 변경되는것을 보여줘야 되기 때문이다.

실제적으로 할때는 자동적으로 처리한후 폼이 사라져야 정상일것이다.

잠시 딴길로 빠져보자..

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=17&MAEULNO=8&no=100860&ref=100860&page=1

사실상 이런 기초셋팅은 XML로 dataTable에 있는 매서드를 이용하면 정말 편리하게 처리할수 있다. 하지만 여러곳에서 사용하기에는 해쉬테이블이 더 편한것은 당연한 사실

그러니 이런 셋팅을 해쉬테이블이나 닷넷 2.0부터 되는 dictionary테이블을 이용해 보도록 하자.

워낙에 단순한 것이라 크게 문제가 없는데..

이론적으로 클래스가 시작될때 파일에 기록된것을 찾고 파일이 없다면 새로 만들고

필요할때 저장하면 되는것이다.



파일이 없다면 이렇게 처리하고

기록은



이런식으로

읽기는..



이런식이 되면 될것이다.

저장된 모습은



이런식의 몰라볼 모습일것이다.

뒷편이 짤려서 그런데 뒤쪽에 보면.. 실제적인 데이터가 string으로 노출될것이다.

해쉬테이블을 이용하였을 경우를 보자.



조금 내용이 작은데.. 하여간.. 이렇게 된다.

뭐.. 지금 작성하는것에 사용하는 설정파일로는 XML이 더 좋겠지만..

가끔은 약간의 보안적 위험을 감수하고서라도 꼭 클라이언트에 DB연결자를 저장하고 싶어하기도 한다. 그럴때는 어떻게 하는게 좋을까?

위의 개방형으로 보이는것을 어떻게? 그렇다. 적당히 암호화 하면 된다.

C#에서는 이런경우를 위한 상세하고도 좋은 암호화 기법이 있다.

하지만 우리는 역시나 졸~ 귀찮다. 물론 권장암호기법을 권한다. 그러나 아주 귀찮다면 또한 적당히 노출되거나 말거나의 위험성이 별로 없다면 이렇게도 가능할것이다.

고전적 방식의 암호화 한줄짜리 암호화를 사용해 보도록 하자. 내가 즐겨 사용하기도 한다.



매우 허접하긴 하지만.. 그런데로.. 우리가 가지고 있는 정보는 보여주지 않는다.

for (int i = 0; i < buffer.Length; i++) buffer[i] = Convert.ToByte( Convert.ToInt32( buffer[i] ) ^ 2) ;

코드만 딱 봐도 알건데.. 아주 고전적 XOR기법이다.

for (int i = 0; i < buffer.Length; i++) buffer[i] = Convert.ToByte( Convert.ToInt32( buffer[i] ) ^ i%177) ;

같이 가벼운 응용도 가능하다.



XOR란게.. 워낙에 고전적인 거라 특별히 설명할만하지가 않다.

모르지 않겠지만 행여나 모른다면 다른 문서들을 찾아서 이게 뭔지 찾아보기 바란다.

전체모습이다.



오른쪽이 좀 잘리는것에 크게 신경쓰지 말고 보면 될것이다.

저걸 다 보이게 하면 데브에서 그림이 찌그러져 보이기 때문이다.

그쪽루틴은 거의 혼자 구현이 가능할것이라고 믿는다.

자. 기초루틴은 다 완성이 된듯 싶다.

DB에 우리의 파일을 넣는것도 되었고 버전이야 알아서 적든지 말던지고

우리는 이제 고민을 해야한다. 과연 전송을 어케 해줄것인가? 한방에 처리해준다면 우리는 압축알고리즘을 추가해서 전송의 효율성을 줄수도 있을것이다.

개별당.. 업데이트는 또한 그 나름대로의 멋이 있다.

그러나 우리는.. 앞서 코딩했듯이 안하는거..

맞다.. 남들은 안하는 이상한 코딩을 하는게 주요목적이다 보니

업데이트에도 이 이상한 방식의 한방(?)을 이용하도록 하자.

이것은 dataTable을 시리얼라이징 해서 그것을 원격지 클라이언트에게 보내고 원격지에서 데이타테이블 또는 데이탓을 복구한다음(Deserializing) 그것을 가지고 파일의 업데이트를 하는것이다.

말그대로 아무도 이딴짓을 안한다.

몇가지 찾다보니 비슷한 유형의 강좌가 하나 있었다. 참고삼아 보도록 하자.

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

이왕 참고적인걸 더 적는다면.

Professional의 닷넷네트워크 프로그래밍

정보문화사의 .net Network programming 이란 책들을 참고하면 될듯 싶다.

---------------------------------------------------------------------------

자.. 위의 이론은 그렇다고 생각하고 이제는 기본적인 통신루틴을 작성할 시기다.

통신은 예전에 길게 이야기 한 바가 있으니..

이번에는 짧게 가자.

일반적으로 대기형태의 소켓과 그리고 접속자가 오면 개별용 소켓이 따로 필요하다.

예를 들어서 내가 sk T에 전화를 걸었을때 처음 접하는건 딱딱한 기계음이고

이녀석은 일종의 대기소켓 이라고 하자.

그리고 뭐.뭐를 누르면 1:1의 상담직원이 나온다. 개별용으로 접속자마다의 상담자도

존재해야 되므로 확실한 1:1이다.

즉 서버란 이와 같다.



그리고 각 개별용 처리루틴은..

클래스로 만들었다.



물론.. 쓰레드와 통신에 대해서 많은걸 아는사람은.. 바로 의의를 제기하겠지만

그냥.. 조용히 덮어두고



폼 클로징에 이런거 하나 넣어주면.. 좋겠다.

이렇게 테스트형 프로그램 서버를 작성했다.

자.. DB가 일단 해결이 되었고

두번째는 뭔가?

드래그 드랍일것이다. 뭔가를 드레그 드랍하려면

컨트롤에 드래그 드랍의 메시지를 받을수 있도록 변경해야 한다.

하지만.. 이렇게 바꾸어도 아무런 표현이 없으니 당최 답답할것이다.

파일을 끌어다 놓으려 해봐도 여전히 불가 표시만 나올것이기 때문이다.

불행(?)히도.. 그 표시까지 우리가 직접 코딩을 해줘야지만 한다.

코딩은 그다지 어렵지 않다. 파일을 우리가 만든 박스위에 가져오면..

이렇게.. 마우스의 표현만 바꾸어 준다는 이야기다.

이제는 파일을 가져다 놓아보아라.. 뭔가 마우스가 변경되었을것이다.

그러나 여전히 아무런 동작을 하지 않을것은 당연지사.. 그 동작도 우리가 만들어 줘야한다는 것이다.

자 가볍게 코드를 넣어주면.. 이렇게 처리가 될것이다.

물론 여기저기.. 불만이 많겠지만.. 그런것들은 당신이 충분히 해결할수 있을거라고 믿는다. 왜냐 나보다는 당신이 더 뛰어난 프로그래머이기 때문일꺼니까..

파일의 생성날짜라든지 그런것은.. Fileinfo에서 충분히 가져올수 있을것이다.

그걸 위해서 이미 적은글을 다 뒤 바꿀수는 없지않겠는가?..

당신이 하면 한줄이지만.. 내가 지금 하면 안습이다.

자 대략의 문제를 해결했다. 그럼.. 이제 DB에 넣기만 하면 되는것인가?

아주 손쉽게도.. 그저 update구문 하나만 호출하면 모든것이 해결이 되는것을 나도 그리고 당신도 알고 있다. 하지만 이렇게 구현을 할 생각은 없다.

사실상 이런? 단순한것들은 바인딩으로 처리하면 마우스 몇번의 클릭을 가지고 모두 다 처리가 된다.

어렵지도 않고 빠르고 이미 일반적인 코딩으로 확정이 되어 있는것이다.

그런건 책보면 되니까..

왜 이런 허접한 이야기를 읽고 있는가?

그렇다.. 가끔 허접하고 삽질인것도 함 봐줘야 하는것이다. 그래야 더 쉬운방법으로 하면서 우리는 행복해 할것이기 때문이다.

참고문서:

http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=45&MAEULNO=18&no=390&page=1

자.. 이제 아주 구차한(?) 코딩을 보도록 하자.

위의 참고문서의 코딩을 조금 바꾼것에 불과할것이다.

오른쪽이 짤리는건.. 데브를 탓하던지.. 그림으로 올리는 나를 탓하던지

하여간.. 적당히 짤리면.. 적당히 채워 넣도록 하길 바란다.

뭐 이런 구질구질(?)한 방식 말고도 더 좋은게 많으니 책을 보도록 하자.

오른쪽을 보면.. 데이터가 들어간게 보인다.

즉 우리의 파일의 내용까지 바이너리로 다 들어간것이다.

뭐 호출이야.. 대충 해도 된다.

이렇게 적든 저렇게 적든.. 알아서 하면 되는거고..

이제.. 통신으로 발길을 돌려보자.