삶이란 긴 이야기 - SungMin

토양이 있어야 농사를 지을수 있다.

연극에 대한 열정이 있다면 연극을 하는것은 문제가 아니다.
그러나 그 연극을 사람들이 봐주지 않는다면 다음연극을 할 수 없다는게
실제적인 문제이다.

그사람의 열정을 우겨놓고 짓발기 보다는 키우려 해보고 보살펴 줘라.

프로그래머 ..
프로그램이란것은
오로지 인간의 열정이 필요한 그 무엇이다.

내가 키보드를 치는것이 엄청난 에너지가 필요한것이 아니다.
하지만 그 입력하는 내용을 만들기 위한 에너지는 한 인간의 심혈이 들어가야 한다는 이야기다.

아무도 자신의 먹을것을 내어놓지 않고 오로지 무엇이 있을까만을 살펴보다가는 모두 다 굶어죽고 말것이다.
더 큰 무엇인가를 위해서는 우리는 한알의 밀알처럼 스스로를 죽여하는것인지도 모른다.

내가.. 그렇다. 아무것도 모르는 내가 계속 무엇인가를 적고 있는 이유는 단순하다.

토양이 있어야 농사를 지을수 있는것이다.
누군가 IT산업에 들어오고 나가고가 문제가 아니다.

그 사업이 생산력이 있는가 없는가가 더 큰문제일것이다.
IT산업이 가치를 생산한다면 인력이 몰리는것은 당연한것들이다.
그리고 가치생산이 없다면 자연스럽게 모든인력들은 다른곳으로 사라질것이다.
공무원을 하다가 할게 없어서 IT를 선택하는것은 아니다. 단지 자신의 현실에서 가치비중이 높았기 때문이라고 생각해 줘라.

그러고 그런문제에 열불을 올리지 말고.
현 IT산업의 좀 더 나아가는 모습을 위해서 자신것을 내어놓아라.
지식산업이란 오로지 두뇌로만 승부해야 되는산업이란것은 내어놓지 못한다면 자신의 것이 사라질까 두려워 혼자만 알고 있다면 그 산업은 멸망의 길로 나갈뿐이다.

내가 다른이의 받침돌이 되고 그리고 나도 다른이의 지지를 삼아 더 높이 올라가야지만 살아남는 산업이란 이야기다.

아직은 처참하게도 내가 적은글 조차 다른곳에 인용될때 한줄의 인용구문도 한줄의 링크도 없이 사용되는 한국의 문화지만 그래도 누군가는 지식을 나누어야지만 그 토양이 큰다는 이야기다.

끊임없이 외국의 사이트나 뒤지고 그런것이 더 많은 지식을 얻는 보고인양 하는것은 결코 현실타개가 아닐것이다. 내어놓아라.
비록 보잘것 없고 하찮은것이라도 내어놓아야지만 한다.

정보는 데이타가 없으면 만들어 지지 않는다. 최소한의 데이타도 없는 사회가 현 한국의 프로그래밍 사회가 되어가게 하지 않았으면 한다.

자 이제 마지막이다.

전체 소스를 공개하도록 하자.

다운은..

http://www.devpia.com/dExpert/?Op=tv&Seq=1220

여기서 받고..

 

받기싫다면.. 다 입력해야지 뭐

개인적으로 생각할때도 받을만한 가치는 없다만.. 그래도 입력하기 싫다면 돈으로 때워야지 어쩌겠니..

 

1. 기본적으로 ms-sql이나 오라클같은 경우에는 지금의 제한사항이 좀 더 유연해진다. 만약 클라이언트가 내부내트웍내에서 디비서버로의 접속 아이디와 패스워드에 소스에 적혀 있음이 문제되지 않는다면 바로 DB에서 데이타테이블을 가져오도록 하면 아주 많은 제약사항을 모두 다 넘길수 있다.

물론 받는동안의 progress는 지원이 안되겠지만.

2. 현재의 제약을 넘기위해서는 파일경로를 DB에 적어놓고 전송할때는 실제 파일을 읽어서 처리하는 형태로 할것이다.

입력하기 싫으면.. 덱스인가 뭔가에서 받으면 된다.

아님.. 직접 작성하면 되고.. 어려운건 참고하고..

하지만.. 지금 뿌려준것과 완벽하게 똑같을것이다.(뭐 한두자 정도는 틀릴수도 있지 뭐 ㅎㅎ)

참고로... mdb는 SP못쓴다. Ibatis라도 써라고 우기거나 구현해라고 우기거나 그러면 싫어할꺼다.

최소한 1강인가 어디서 view스타일의 외부 쿼리쓰는법은 알려줬으니 그걸 응용해라.

언젠가 잠시(?) 또 한번쯤 맞이가면.. Ibatis비스무리 한거라도 함 만들어 보자.

그런데 이제 MDB는 거의.. 뭐 아니지 않는가 ^^

전체소스는…………..



이렇게 구성되어 있으며 강좌내에서 보다는 많이 변경되었다. 동일한 소스이지만 효용성을 위해서 클래스로 다시금 작성구조를 변경해 두었다.

서버부터 보도록 하자.~~~~~~~~~~~~~~~~~~~~~~~~~```

만약 정상적으로 보이지 않는다면 다운받거나 해서 보면 된다. 데브의 제한과 그리고 소스자체가 길다.









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

클라이언트

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







클라이언트 폼의 소스

예제를 위해서 Test프로젝트를 하나 만들자.







소스는 단 한줄이면 된다.

당연히 저 한줄을 위해서는..



참조에.. 우리가 만든 클라이언트를 포함시켜 줘야 한다.



클라이언트 소스는 이런식으로 작성해 줬다.

즉.. 실행하는 녀석의 program의 이름을 알아낸다음..

그것을 기본 세팅파일에 저장한다.



그러면.. 실제적으로 자동 업데이트를 호출하는 녀석을 알게되므로

업데이트 후에는.. 이녀석을 다시금 실행하면 되는것이다.



너무 어렵다고 생각된다면 하나만 기억하자.

새롭게 만든 프로젝트에.. 단지 한줄만 적어주면 자동으로 업데이트를 체크해서 업데이트할것이 있다면





라고 메시지가 나오고 확인을 누르면 업데이트가 되고 다시금 호출한 프로그램이 실행되는것이란 이야기다.

일단은 프로젝트를 받게되면 제일먼저 해줘야 하는것은..



셋팅클래스에서 서버의 주소를 적어줘야 한다. 이것때문에 셋팅데이타를 XML로 하려고 했으나 강좌의 진행상 ^^ 다른파일로 처리가 되었다.



여기서 서버의 아이피만 적어준다면 쉽게 로컬에서도 테스트가 될것이다.

단 로컬에서 한다면 너무 빨리 처리가 되어서 업데이트 화면이 뜨고 사라짐에도 볼수 없는 속도로 업데이트가 끝날것이다.

실제적인 서버아이피만 설정해서 컴파일 한다면 소스의 수정이 없는 상태로 대부분의 프로젝트에서

호출시 한줄만 선언해주면 알아서 업데이트를 처리할것이다.

물론 이 서버를 여러가지 업데이트가 가능하도록 처리하겠다면

서버의 테이블부터 조금 변경해야 될것이다.

서버가 작동중이지 않을때를 대비해서 체크루틴은 쓰레드로 처리했으며 일반적으로 프로그램이 실행될때는 속도차이는 없다고 봐도 좋다.

이것의 응용으로 MDB를 하나의 서버로 이용할수도 있다.

이론적으로 가능하지만 ? 굳이 그렇게 사용하려고 할만한 사람은 없을꺼라고 믿는다.

왜냐면 ms-sql Express가 이미 무료로 배포가 되니까 말이다.

사용법

사용법은 너무 단순하고 쉽다.

일단 서버를 실행한다.



왼쪽에 업그레이드할 파일을 드레그 드랍한다.



입력버튼을 누른다.



오른쪽으로 데이터가 이동되었을것이다.

서버대기를 누른다.



모든것은 끝났다. 서버는 이것으로 모든셋팅이 끝이다.

물론 version이던지 inputdate는 왼쪽의 그리드에서 스스로 입력해도 된다.

그것은 자신의 기준이다. 현재로서는 드래그하는 날짜를 기준으로 자동입력이 될것이다.

여기서 첫번째 그림에서 보듯이 여러가지 파일중 방금 추가한것에 대해서만 클라이언트가 받게될것이다.

클라이언트의 폴더를 보자.



박화요비라는 파일은 보이지 않는다. 클라이언트를 실행하자.



하나의 파일이 증가됨을 알수 있다.

예를 들어서 클라이언트에서 실수로 모든 파일을 지웠음을 예상해보자.



이상태에서 클라이언트를 실행해본들 아무런 효용성이 없다.

왜냐면.. 기본적인 setting.bin에 기록된 기준날자로 인해서 DB에서 쿼리를 해서 업데이트를 받아올것이기 때문이다.

그러므로 이경우는 setting.bin을 삭제해주면 초기화가 될것이고 그 뒤에 업데이트된 프로그램에 한해서

다시금 다운을 받게 될것이다.



지워주고 실행한다.



정상적으로 전체파일을 받아오게 된다.

또한



이런식의 같은파일을 두개를 입력했을경우를 보자. 왜냐면 업데이트란것은 항상 같은 파일이름이 언제나 서버에 중복적으로 생겨야 하기때문이다.

뒤에 inputdate에 따라 결국 어느것이 더 최신인가를 판단하게 될것이다.

select *

from AutoUpdate, (SELECT filename as FN, Max(inputdate) as Idate FROM AutoUpdate AUT group by filename)

where filename = FN and inputdate = Idate;

이런 쿼리를 사용하여 중복의 경우는 최근에 입력한것에 대해서만 클라이언트에게 나가게 될것이다.

실제적인 모습은.



이렇게 하나만 나오게 될것이다.

물론 실제적으로 이렇게 끌어다 입력을 하더라도 실제적으로 화면에는 나오지 않을것이다.

여하튼.. 두개가 있는 것중 최신것이 내려질것이다.

예를 들어



최신파일을.. 수작업으로 5000으로 한정지었다.

즉.. 옛날 파일이 있더라도.. 더 최신파일로 업데이트를 해야되므로 말이다.



이 형태에서

아래처럼.. 최신파일로 업데이트 되었음을 보여준다.



정상적으로 처리가 된다.

자.. 상당히 정신이 없을것 같다.

나름 쉽게 적는다고 쉽게 적었다만 오히려 쉽게 적는다고 더 코드가 왔다 갔다 하는덕에

오해를 하지 않을까 싶다.

하여간 전체 소스를 보게 되면 실제적으로 중요코딩은.. 10줄 이내고

핵심적인건 100여줄이 안된다는걸 알게될것이다.

크게 어려운게 아니니 쉽게 이해하리라 믿는다.

자 이제 DS을 통해서 그 정보를 파일로 저장하는것을 해보자.



사실 저장은 따로 말할만하게 없다.

그냥.. 하면 되는것이니 말이다.

이제 모든게 처리되었다.

프로세서를 통해서 실행하는것은 이미 알고 있을꺼라고 믿고

또한 EXE 파일을 참조로 끌어들여서 최신버전을 체크하는것 또한 잘 할꺼라고 믿는다.

아.. 별거아닌걸 하나를 빠뜨린것 같다.

다운을 받고나서는 또는 파일로 다 기록을 한 뒤에는 자체적인 Lastdate 변수에 오늘받은것의 기준날짜를 기록해주고 그것을 기록해야 할것이다.

그러면.. 다시 업데이트를 할때 기준날짜를 기준으로 해서 업데이트를 할것이 없으므로 인해서

서버에 새로운게 있지 않는이상 업데이트가 되지 않을것이다.



이제 고민할것은 실제적인 이녀석의 실행이다.

과연 어떻게 실행할것인가? 이것이 사실상의 코딩보다 더 중요한 입장이다.

예를들어서 VS가 실행할때마다 업그레이드를 확인한다고 생각해 보자.

또는 한글워드를 생각해보도록 하자.

이런어플리케이션들은 실제적으로 자주운용이 되는 입장에서 여러모로 서버에게 부하가 가중될수도 있다. 그럼 어떤방식으로 운영이 되는가?

한글워드의 경우 업데이트 프로그램이 별도로 있는입장에서 레지스트리를 이용해서 이 프로그램이 실행되는걸로 알고있다.

하지만 네트웍 프로그램들을 살펴보자. Ndisk나 sun폴더 또는

대신증권같은 소프트웨어를 보자. 이런것들은 실제적으로 항상 서버에서 전해주는 기준적인 프로토콜이 생명일뿐이 아니라 항상 네트웍으로 연결이 필요한것들이다. 이런경우의 소프트웨어는 항상 실행할때마다 업데이트를 체크해야 할것이다.

그럼 우리가 만드는 소프트웨어는 어떻게 하는게 좋을까?

그렇다 이건 당신의 문제라는 것이다.

일단은 지금은 가볍게 함수를 하나 만들어서 처리를 하자.

최종요약

1. 이것은 소규모에나 사용될수 있는 업데이트다.

즉 규모가 크면 불가하다. 만약 큰파일도 전송을 해야된다면 실제적인 파일은 데이타들은 외부에 둔상태로 있어야 한다. 즉 DB에 데이터를 넣지 않고 외부파일을 통신으로 전송하는 방식으로 하면 현재의 모든 문제는 (sirialize의 메모리 오류가 나오는 문제와 그외 등등)은 해결이 된다.

또는 드물겠지만. 클라이언트에서 바로 DB로 접근을 해서 Dataset을 받아오는것도 나쁘지는 않다.

하지만 이경우 DB접속패스워드의 보안상의 문제점 MDB를 이용할수 없고 대규모형 sql를 사용해야지 할것이다.

2. 앞쪽에서 설명하지 않고 그냥 지나왔지만 실제적인 DB에서 쿼리는 Max를 사용해 주어서 중복되는것은 inputdate의 최신날짜의것을 가져와야 한다. 업데이트의 속성상 항상 같은 이름으로 파일이 저장될것이기 때문이다.

3. MDB는 일종의 View의 개념을 지원한다. 즉 MDB파일내에 쿼리를 넣고 C#에서는 단지 그 이름만 호출이 가능하다는 것이다. 앞서 예제를 보여주었다. 즉 쿼리는 사실상 mdb에 넣어두는게 변경에 용의할것이다.

4. 바인딩을 사용하게 된다면 이 소스의 50%는 줄일수 있다.

게다가 더 효율적이고 기능도 더 많을것이다. 게다가 더 안정적이고 그러지 않은것에 대해서 묻지는 않길 바란다.

4. 현재는 설명을 위해서 중구난방으로 되어 있다.

실제적인 활용을 위해서는 각 루틴을 클래스로 만들어야지만 할것이다. 그래서 서버의 소켓 / 클라이언트의 소켓을 따로 분리시키고 이 폼이 아니더라도 다른곳에 붙이기 쉽도록 변경했다.

디렉토리부분은 구현해 놓지 않았다. 추가는 스스로 할수 있으리라 믿는다.

전체소스는 MDB를 포함하여

올려두었다.

또한 입력하는 사람을 위하여 클래스별로 올려놓았다. 이미지가 작게 나오는건 데브를 탓하기 바란다.

5. 파일전송에 대한 포스팅은 시간이 되는데로 새로운 프로젝트로 새로운 강좌에서 시작해 보자.

그냥 코딩만 나열하면 될텐데 정말.. 말이 많다.

하여간.. 계속 진도를 나가자.

접속을 하면 Ready를 받고 앞에 4byte에 다가는 뒤에 들어갈 녀석의 사이즈를 담아서 보내자

물론.. 이건 일반적이고 우리는 참 무식하게 해보자. 이번에는 스트링을 가지고 해보자.

좀 황당하긴 해도 재미있지 않겠는가?

통신의 규칙은 스스로 만드는것이란걸 보여주고 싶다.

그럼.. 자 어떻게 해볼까. 10바이트에 내가 보낼 사이즈를 보내준다고 생각해보자.(말도 안되는 이야기 이긴하다)

예를 들어서 내가 보낼 사이즈가 56789 란 사이즈라면.. 0000056789 라고 보내줘야 될것이다.

그러기 위해서 PadLeft를 사용해서 빈곳에 0을 채워주겠다.

(이런방식은 실제적인 통신프로그램에서 사용되지 않는다고 확신한다. 매우 비효율적인듯 싶다.)

앞서 이야기 했듯이 버퍼에 정보가 들어가는 입장이므로 사이즈를 받고 공간을 마련해서 뒷쪽의 정보를 받는 찰라의 순간에 데이터가 날러갈지 잘못될지 걱정하지 마라.

자.. 사이즈를 보내고 바로 정보를 보내면 된다.



여지없이 잘 온다. 사이즈는 1555라는 이야기고 이제 서버와 클라이언트의 소스를 보자.

앞서 시리얼 라이징은 지겹게 했으니 잘 알것이다.



클라이언트에서 보내는 코드이다.

MemoryStrem에 개체를 넣고 바이트로 넘겨줬다.

그럼 그것을 받는 서버는



간단하다. 이런 간단루틴만으로 우리는 실제적인 dictionary에 있는 각종정보

예를 들어서

아이디 / 패스워드 / 기준날짜 등등..을 아주 손쉽게 전송할수 있게되는것이다.

자 이정도 했다면 이제 우리는 앞서 우리가 정의했던 기본적인것의 처리를 한듯 싶다. 이제 이 정보를 가지고 로그인에 대한 설정은 스스로 하기로 하고 난 무조건 ok라고 생각하기로 하고

클라이언트에게 정보를 보내야 하는것이다.

4byte를 기준으로 good이라고 보내면 그 뒤로 기준데이타를 가지고 업데이트할 정보를 보내주고 fail 이라고 보내면 클라이언트는 업데이트할것이 없다고 생각하고 종료를 하자.

위와 동일한 수순을 처리하면..



손쉽게 클라이언트에서 서버에서 제공하는 데이타셋을 받아온것을 볼 수 있다.

뒤에 filedata라는 바이너리까지 정상적으로 받아온다.

앞서 적은것은 일단 이론적인것을 설명하기 위한것이니 기본적 참고만 하고

이제 전체 소스를 적어보도록 하자.

일단은



이 함수들은 클라이언트에도 그리고 서버에도 있는 공통함수로서 TCP의 버퍼에 있는정보를

가져오는 함수이다.

이걸 제외한 클래스를 보자.

먼저 서버는



EachByClass는 접속자마다 인스턴스가 생기는것으로

접속자마다의 쓰레드가 도는상태내에서 통신의 핸드쉐이킹(?)적인 형태의 신호를 주고 받고 그런다음 클라이언트에서 주는 정보를 기준으로 쿼리를 날려서 이 데이타셋을 클라이언트에게 전송해준다.



다수의 클라이언트가 접속했다는 가정내에서 테스트 해본 화면이다.

클라이언트의 경우는..



이런 형태의 모습을 지닌다.

자 이제는.. 마지막으로 DS 를 가지고 하드에 저장만 하면 된다.. ^^ 별 어려울게 없을듯 싶다.

아 프로그래스바? 그거야 쉽지 않는가.

조금 융통성 있게 구성해도 좋지만.. 귀차니즘으로 쉽게 하자면



이렇게 두줄만.. 적어주면.. 된다.

자. 얼핏 적는다는게 벌써 여기까지 왔다.

네트웍을 처리해야 하는데 기초적인 네트웍을 살펴보자.

서버는 이미 앞에서도 대충 이야기 했으니

기본적인것만.. 소스를 나타내 보자.



예를 들어서 이런식으로.. 서버를 코딩하고

클라이언트를..



이런식으로 했다고 하자.

그럼.. 결국 서버와 클라이언트는 정보를 주거니 받거니 할것이다.

서버의 출력창 모습은



클라이언트의 출력창 모습은..



이런식으로 나오게 될것이다.

위의 코드를 대충 까발려서 머리에 안들어 올것인데

A -B에서 하나씩 정보를 주고 받고..를 하는것이다.

Bow를 보내면.. bowOK를 보내고

End를 보내면 endOK를 보내는 식으로 서로의 정보를 주고 받는 모습을 가볍게 보여주고자 하는 코딩이다.

왜 이걸했냐?

결국 자동업그레이드는

처음 접속해서 접속이 올바르게 되었다면..

두번째로는.. 업그레이드 할 내용을 받아야 하고

세번째로는 업그레이드의 대상파일을 받아야 한다.

네번째는.. 그 파일을 기록해야겠다.

즉 준비적인 sign이 있어야 한다는 이야기다. 포수와 투수처럼 미리 달라고 해야되는 사인을

표현해주기 위해서 이렇게 코딩을 했다.

예를 조금 더 들자면 아이디와 패스워드를 받는다던지 또는 서버의 경우 하나의 프로그램 프로젝트에 대해서만 업그레이드를 수행할 이유는 없는것이다. 즉 클라이언트에서 그 프로그램의 아이디를 요청하는것에 대해서만 정보를 전달해서 업그레이드를 해주기만 하면 된다.

그런 실제적인 작업을 위해서는 정보의 교환이 필요하게 된다.

하지만 우리는.. 단순 그리고 무식하게 코딩을 처리하도록 하자.

1. 서버로 접속을 하게 되면 무조건 Ready를 받게된다.

그러면 클라이언트는

ID와 password 그리고 업그레이드 받아야 되는 고유 programID를 기준날짜등을

담아서 dictionary로 개체 전송을 하자.

2. 서버에서 정보를 받고나서

상태를 보관하는 특정한 변수에 LoginOK = true같은 설정을 처리하고(아이디 패스워드가 정상일때)

"LoginOK"라는 문자를 클라이언트에게 보내도록 하자.

물론 "LoginFalse"라고 보내면 접속을 끊자.

3. 서버

getFile이란 정보를 취득하면 LoginOK라는 변수에 true 인지 확인후 파일을 담고 있는 dataset을 전송하자.

서버와 클라이언트간의 정보이동을.. 그림을 그려주고 싶지만.

그러기에는 ^^ 조금 안습이다.

실제적인 코딩을 하면서 다시금.. 설명이 들어가니 그때 보고 이해를 하자.

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

자 기초적인건 머리에 넣었다고 생각한다.

TCP의 통신에서 가끔 엉뚱한 상상을 하는 사람이 있어서 또 예제를 더불어 놓는다.

그림을 그려야 하는데 말이다. 참 힘들다. 그러니 그냥 가자.

일단.. 가끔가다보면 substring을 사용하는 사람들이 있다. 물론 이걸 사용하지 말라는건 아니고 기본적으로 Buffer란 개념이 없기 때문이 아닌가 하고 짐작해 본다.

또한 (이번에는 링크를 안때리겠다.) 최근의 질단란을 뒤지다 보면

TCP가 끝이 없다. 라든지 같은 말들이 있는데 틀린말은 아니다. 단지 그것을 운영하는 방법이 필요할 뿐이란 것이다.

TCP는.. 우리가 소켓을 만들면 하나의 버퍼가 준비가 된다. 이 버퍼에는 상대방이 보낸것이 고스란히 저장이 되는것이다. 그럼 뭔가 ? 우리는 그 버퍼에서 가져다가 사용만 하는것이란 이야기다.

예를 들어서



이런식의 코딩을 했다고 하자.

그럼.. 우리는 이것이 한번 보내지고 그 데이터를 적시에 받지 못하면 데이터가 사라진다고 생각하는것이다. 누가 이런생각을 하는건지 모르겠으나. 가끔 보다 보면.. 그런사람들이 있다.

이 데이터는 고스란히 상대편의 버퍼에 저장이 된다.

상대편의 코드에 이런식으로 코딩을 해보자.



이 코드는.. 2바이트씩 받아서 그것을 출력해주는 함수이다.

이걸 이용해서 이런 코딩을 해보자.



즉.. 2글짜씩 두번 뿌려주고.. 3초 있다가.. 버퍼에서 다시금 2바이트 가져오고

다시 3초 있다가 2바이트를 가져온다.



내가 신이 아닌인상 이렇게 2개만 잡을수는 없을것이다.



이제 3개를.. 즉 이렇게 할수 있다는것은



이런식이 된다는것은 무엇인가?

이미 클라이언트에서 정보를 보낸것은 종료했다. 정보는 이미 보내고 가져오는것은 늦게 가져올수 있다는 이야기다.

왜냐면.. 그 정보들은 내 버퍼에 있기 때문이다.

이번에는



이렇게 보내보자.

당연히 결과는 동일하다. 이미 버퍼의 앞쪽에 위치한것이 나가지 않는이상 뒤의 것을 읽지 못한다.

버퍼를 비워주지 않는이상 뒤의것을 받아들일수는 없다.

물론 읽기야 읽지..



저기 보면.. Offset이라고 적혀 있는것이 보일것이다. 그래서 저게 오프셋이다.

버퍼의 내용을 어떻게 가져오는냐 하는 이야기란 말이다.

내가 보낸것은 버퍼에 들어가지 바로 받지 않는다고 못 받는것은 아니다.

물론 못 받는 통신이 UDP다 이건 지금 이야기 할것이 아니니 다음에 이야기 하고

TCP는 기본적으로 버퍼 구조라는 개념을 머리에 확실히 넣어줘야 잘 사용할수 있다.

TCP의 통신은 실시간이 아니다.(물론 실시간이다만.. 어케 적당히 표현이 안된다.)

당신의 기초개념이 흔들이면 여지없이 코딩은 끝장나게 흔들린다는 이말이다.

자 다시금 돌아와서



이번에는. 4byte씩 읽도록 했다. 위의 코딩의 890 뒤에서 끊어지는 신호는 없다.

바로 ABC가 들어온다는 것이다.

자 그럼 어떻게 할까? 이문제는 당신이 풀어야 한다. 왜냐면 프로그래머는 규칙에 따라서 살기도 하지만 항상 규칙을 만드는게 프로그램의 즐거움 아니겠는가?

Ps) 데브에 언제 트랙백 기능이 생길런지는 모르겠다만..

만약 이런 오류에 시달리게 된다면..

http://www.hoons.kr/board.aspx?Name=QACSHAP&Mode=2&BoardIdx=14344&Key=&Value=

http://www.codesos.com/book/network/WSACancelBlockingCall.html

이문서를 참고해라.

쉽게 말하자면.. 먼저쓰레드 날리고 소켓 날리면 될것이다.

 

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

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



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

폼은.



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

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

잠시 딴길로 빠져보자..

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

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

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

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

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

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

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

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

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

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

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

허접한 자동업그레이드를 하나 만들어 보자.

 

일단 이론을.. 정립을 좀 하자.

업그레이드는 너무나도 많이 있으니 기초이론생략하고 내가 만드는것에 따른 이론을 정립하자.

서버측은 DB 에.. 이 DB는 MDB로 해서 업데이트할 데이터를 드레그인 하면.. 그녀석들이 자동으로

DB에 저장이 되고 자동 버전(?) 시스템으로 처리된 상황에서 모든게 끝이다.

두번째로 클라이언트측은 update.exe로 처리해서 서버에 접속해서 DataSet을 받아온다.

그 데이타셋은 기본적으로 1차.. 업데이트할 녀석의 목록과 파일의 크기가 되겠다.

두번째 실제적인 파일의 정보를 받아온다. 이건 귀차니즘?으로 한방에 처리할지 따로 처리해줄지 아직 정하지 않았다.

한방에(?) 처리하는걸로 기준을 삼고 있다.

이렇게 하게 되면

 

1. 단점..

1-1서버에 항상 서버용 프로그램이 있어야 한다. 즉 실행되어 있어야 하고 대기해야 한다.

1-2 오로지 소규모의 작은파일만 가능하다. 만약 전체 시리얼라이징해야 되는 크기가 대략.. 50메가가 넘어간다면.. OutOfMemoryException이 발생할것이다. 정확하게 어느정도 까지 인지는 모르겠으나.. 20메가까지는 대략의 테스트 결과 문제없었던듯 싶다.

MDB의 크기는 대략 1기가까지는 테스트 해본결과 문제없이 잘 돌아간다.

물론 그정도 사이즈 까지도 사용할일은 없다고 본다.

해결법은.. 제일뒷쪽편에서 적어두겠다.

 

2. 장점

2-1 Http나 ftp로 하는게 아니라서 그냥.. 프로그램 실행만 하면 된다.

2-2 파일의 관리가 매우 용의하게 된다.

 

요약

한번에 업데이트할 용량이 50메가 이상이면 유용하지 않다.

파일이 많은 업데이트에 매우 유용하다.

만약 이와같은 단점을 커버하기 위해서라면 시리얼라이징이 이난 형태로 구현을 해야한다. 또는 분활형 으로 알고리즘을 수정하면 된다.

그러나 그럴필요는 아직 느끼지 못한다 왜냐면. 한번에 50메가가 넘어갈 수준의 업데이트가 있다면 자동업데이트 루틴을 따로 작성할만한 프로젝트일껏이기 때문이다.

말을 짧게 하자.

그냥.. 코딩 바로 하자.

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

서버 코딩 들어가자.





이런식으로 폼을 만들었다.

물론.. 딱 봐도 더 추가 해야될것들이 하나둘이 아니구나.

뭐 그건 나중에 생각하자.

왼쪽으로 파일을 드래그 드랍해면.. 그 파일의 이름과 크기를 읽어오도록 하자.

그리고 그 왼쪽걸.. 오른쪽으로 옮기고 파일입력 버튼을 누르면.. 실제적으로 DB에 들어가는것으로 이 코딩을 처리하자.

마지막으로 제일위에 있는 서버대기는.. 실제적인 TCP를 대기하는것으로 코딩을 하자.

심풀하다.

자 DB를 설계하자.



이렇게 만들어 보자.

이것을 복사해서 Preparation 테이블을 하나 더 만들자.

자동으로 바인딩을 하면 좋겠지만 그런건 아쉽지 않겠는가?

이런글은.. 이미 책에 있는걸 적으면 재미가 없지 않는가 그럴바에 책을 보지 말이다.

그러니 이상한(?) 방식으로 하자.





대충.. 이런거야.. 이미 다른쪽에서 다 설명을 했으니 설명할 가치는 없다고 생각한다.



위의 내용을.. 솔류션에 CS파일을 하나 추가해서 대충 넣어주자.

자 그럼.. 폼에서는 뭘 해줘야 하는가?



이런식으로 하자.



실행의 화면을 보여주기 위해서 잠시 이상한 데이터를 넣어보았다.

dgvInput.DataSource = DB.callSP("test").Tables[0];

에 주목을 하자면.. 우리는 사실상 MDB 에서 프로시저 개념처럼 잘 사용하지 않는데 저 test는 쿼리를 말한다.



그저 연습삼에 보여주기 위해서 이렇게 작성해 두었다.

MDB파일 내에서 쿼리를 제어하게 되는 모습을 보여주고 싶었다. ㅠ.ㅠ

물론 쓸때는 없지만..

나이가 들었다.

항상 다시산다면 이러지 않을껀데라는 생각이 가끔들었는데 어쩌면 다시 살아도 마찬가지가 아닐까?

경기가 좋지 않다고 한다. 별로 모르고 사는데 오늘따라 왠지 그렇게 느껴진다.

문득 옛 생각에 잠시 나가서 “에이스” 크래커를 사러갔는데 천원이다.

천원에 3개를 사고도 100원이 남던것이 어느덧 천원이 되어 버렸다.

은근슬쩍 아쉽다.

나 자신에게 삶을 포기하지 말라고 타이른다.

현 집권자에게 그러고 싶다. 포기하지 말라고 잘 해보라고

원망은 할만큼 했다. 이젠 좀 해봐야 되지 않겠냐

낼 부터 주식이라도 좀 사야겠다.

오늘 내가 느끼는건 절망이다.

주식이 꽃피는 시기는 내가 절망을 느꼈을때부터이니까. 낼부터 주식이 오를것 같다.

컴퓨터가 살짝 갔다. 어쩔수 없이 다나와사이트를 접속했는데 메모리가 1기가에 만원이다.

만원…….

그래 삼성 맛이갔다. 그래 삼성전자를 사자.

나는 기본적으로 내가 아는 모든걸 공개하지는 않는다.
하지만 50%는 공개하자는 개념을 가지고 있다.

기업은 반드시 개발비를 재투자해야 한다.
그 개발비를 통해서 나오는 기술을 가지고 새로운걸 만들어서 기업의 앞날을 만들어가기 때문이다.

허면 개인은 뭔가?
자신의 이익을 축적하기 위한 책을 사보는것들?

그렇다. 당신이 거기까지만 이야기 한다면 그럼 책을 쓰는 사람은 뭔가 말이다.

사람은 사람사이에 있어야 한다는 이야기 처럼 반드시 자극을 받고 그 자극에 반응을 하게된다는 이야기다.

당신이 내어놓는 지식이 있어야지만 사회의 전체구조가 프로세서가 돌아갈것이다. 기업이 재투자비용을 들이지 않는다면 그 기업은 폐업을 하는수 밖에 없다.

당신이 당신의 지식을 나누지 않는다면 프로그램 세계는 발전하지 않을것이다.