자동업그레이드 3

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

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이다.

즉 서버란 이와 같다.



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

클래스로 만들었다.



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

그냥.. 조용히 덮어두고



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

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