posted by By훈트 2016.02.04 16:41





백팩킹을 시작하기위해 이것저것 알아보고 준비하던 중에

지인을 통해 알게된 2016 국제캠핑페어 정보가 있어 이렇게 글을적어봅니다.


2월 26일(금)~2월 28일(일) 킨텍스 7,8홀 에서 미니멀웍스가 참가한다고합니다.


아래 링크 방문하시면 초대권을 받을수 있는 이벤트도 안되도고 있으니 

관심있으신분들은 링크클릭!!


2016 국제캠핑페어에는 과연 어떤 텐트들이 나오게될지 궁금궁금 꼭 가보고싶은 전시~~


링크 : http://blog.naver.com/mnmalworks/220614879298





저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'백팽킹 > 이벤트정보' 카테고리의 다른 글

2016 국제캠핑페어와 미니멀웍스가 함께~  (0) 2016.02.04
Git
posted by By훈트 2014.12.22 21:36

작은 솔루션회사의 개발자이다. 


회사의 규모가 작다보니 개발인원이 10명도 채 안되는 소규모팀이다. 회사에서는 소스코드관리를 MicoroSoft 사의 Visual SourceSafe(이하 VSS)를 이용해 왔다. 


내가 그간 사용하면서 느낀 VSS장점은 간단하게 아래와 같다.

1. 같은 소스에 대해서 한 사용자가 수정을위해 체크아웃을 하면, 다른사용자는 수정을 할 수 없다.

2. MicroSoft 사의 Visual Studio와 연동이되어 사용이 편리하다.

3. 파일단위로 소스버전관리가 가능하여 파일단위의 부분롤백이 가능하다.


적은인원의 프로젝트팀이나 규모가 작은 프로젝트를 소수로 진행하거나 유지보수할때에는 VSS는 사용하기 편리한 장점이있다.


하지만 VSS는 아래와같이 여러가지 단점도 있다.

1. 파트별로 소스를 관리하게되는 경우 해당파트 담당자가 자리를 비울경우 문제 처리가 어렵다.

2. 동일소스 동시수정이 불가능하여 많은 인원이 공동개발하는 대형 프로젝트에는 사용이 부적합하다.

3. 중앙통합관리 방식인 VSS는 중앙서버에 문제가 생기면 소스관리시스템을 이용할수 없다.

4. VisualStudio가 아닌 다른 개발툴에서는 소스는 관리가 불가능하다. (Eclipse, IOS 등)


나는 VisualStudio를 이용하여 C#을 이용한 윈폼 솔루션을 개발해왔고 특정파트만을 담당하여 관리해왔다. 추가로 이 솔루션을 지원하는 모바일 Android 앱을 개발하여 서비스하고 있다. 

그동안 윈폼 쪽은 내가 담당한 파트에 한해서만 개발하고 수정해왔고 모바일은 내가 단일개발로 진행해왔기 때문에 특별히 소스관리가 필요하지 않아서 VSS의 사용만으로 크게 무리는 없었다.


하지만 백업 인원의 충원과 업무 공유차원에서 다른사람과 공동으로 진행하는일이 점점 많아지고..

특히 모바일 앱의 개발 및 유지보수를 다른이와 공동으로 해야하는 상황에 오고보니 VSS로는 역부족이어서 대체 소스관리시스템에 대해 찾아보았다.


소스관리 시스템을 알아보며 크게 중요시한 사항들은 아래와 같다.

1. 현재 개발중인 MS의 VisualStudio의 C# 와 Eclipse 의 Android 프로젝트의 툴 지원여부.

2. 프로젝트 소스관리에 있어서 자유로운 공동개발과 버젼관리.

3. 소스관리는 중앙집중방식이아닌 분산버전관리방식.(Main 소스관리서버에 문제가생겨도 기존작업에 문제를 주지않고 소스 백업 및 복원까지 가능한)


이래저래 검색도중 SVN Git 에 대한 글들이 많이 보였다. 이중 위 요건에도 모두 충족하며 SVN보다 다양하고 좋은 기능들을 갖춘 Git을 선택했다. Git에대해 1주일정도 개념이해부터 설치와 활용등 VisualStudio와 Eclipse 툴을 통해 격은 내용들을 정리해보고자한다.



혹시 SVN과 Git의 차이첨에 대해 궁금하거나 어떤걸 쓸지 고민중이라면 아래 링크의 블로그 글을 읽어보면 조금 도움이 될거같다.

1. SVN과 Git의 비교와 Git의 차별점을 다룬

출처 : http://seungzzang.blogspot.kr/2013/04/git-svn-svn-git.html


2. SVN을 쓸까? Git을 쓸까? 고민에 대해 다룬

출처 : http://allofsoftware.net/entry/SVNGIT 

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2012.02.27 11:35

 출처 - http://www.cyworld.com/gaephlhome2/7832995 


낭비를 제거하라

 - 소프트웨어 개발에서의 가장 큰 낭비 세가지

   : 가외기능 (80%의 가치를 제공하는 20%의 기능에 초점을 맞춰 개발하는 프로세스가 필요하다)

   : 혼란 (요구사항 혼란을 겪는 다면 스펙을 너무 일찍 결정한 것이다. 테스트하고 수정하는데 혼란을

             겪는 다면 테스트를 너무 늦게 하는 것이다.)

   : 경계넘어가기 (조직간의 경계는 통상 25% 이상의 비용을 증가시키는데, 버퍼를 만들고 응답시간을

                         늦푸며 커뮤니케이션을 방해하기 때문이다.)

 

품질을 내재화하라

 - 검증단계에서 늘상 결점이 발견된다면 그 프로세스에 결함이 있는 것이다.

   : 테스트 주도 개발을 통해 코드의 실수를 방지하라. (요구사항 문서 대신 실행 가능한 명세를 작성하라.)

   : 레거시 코드를 만들지 마라. (레거시 코드는 자동화된 단위 테슨트와 인수 테스트가 없는 코드다.)

   : 빅뱅 통합은 진부하다. (지속적 통합과 중첩된 동기화 기법을 사용하라.)

 

지식을 창출하라.

 - 계획은 유용한 것이며, 학습은 필수적인 것이다.

   : 과학적 방법을 사용하라. (가설을 세우고, 신속하게 다양한 실험을 해보고, 문서를 간결하게 작성하고, 최선의

                                        대안을 구현할 수 있도록 답을 가르쳐라.)

   : 표준은 도전받고 개선되기 위해 존재한다. (모든 사람들이 따라하고 잘 알려진 실천법을 표준에 포함하되,

                                                               누구든지 표준에 도전하고 변경하도록 장려한다. )

   : 예측 가능한 성과는 피드백에 기반한다. (예측 가능한 조직은 미래를 추측하고 그것을 계획이라고 하지 않으며,

                                                         그 보다는 미래가 펼쳐질 때 신속하게 대응하기 위한 역량을 개발한다.)

 

확정을 늦춰라

 - 완벽한 명세서를 가지고 개발을 시작하는 것이 좋은 아이디어라는 생각을 버려라

   : 의존성을 깨뜨려라 (시스템 아키텍처는 언제 어떤 기능이 추가 되더라도 그것을 수용할 수 있어야 한다.

   : 옵션을 유지하라 (코드를 실험으로 생각하라. 변화를 수용 할 수 있게 작성하라.)

   : 돌이킬 수 없는 결정은 마지막 결정의 순간에 하라. (돌이키 ㄹ수 없는 결정을 내리기 전에 가능한 많이 학습)

 

빨리 인도하라.

 -  리스트와 대리열은 일의 속도를 늦추는 조직간의 버퍼다.

   : 신속한 인도, 고 품질, 저 비용은 공존할 수 있다. (속도의 경쟁에서 승리하는 회사는 큰 비용우위를 갖고

                                                                     월등한 품질의 제품을 인도하며 고객의 요구에 더 귀기울인다.)

   : 대기행렬이론을 개발에 적용하라. (가동률을 강조하면 오히려 정체를 일으켜 가동률이 떨어진다.

                                                    배치 크기를 작게하고 진행중인 작업량을 줄여 주기시간을 줄여라)

   : 일의 양을 할 수 있는 만큼으로 제한하라. (반복 개발에 안정적이고 반복가능한 속도를 가져라.

                                                고객에게 인도할 수 있는 역량에 맞게 대기열의 길이를 정지적으로 제한하라.)

 

사람을 존중하라.

 - 주도적으로 참여하고 연구하는 사람들이 최고의 지속가능한 경쟁 우위를 제공한다.

   : 팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다.

                           (무엇이 팀을 만드는가? 팀원들은 공동 목표를 달성하기 위해 상호간 책임의식으로 뭉쳐있다.)

   : 효과적인 리더쉽을 제공하라. (효과적인 팀에는 팀을 최고로 이끄는 훌륭한 리더가 존재한다.)

   : 파트너를 존중하라. (조인트 벤처를 위한 헌신은 절대로 이해상ㄹ반을 만들지 않는다.)

 

전체를 최적화하라.

 - 빼어난 제품은 기회와 기술의 특별한 만남에서 나온다.

   : 전체 가치 흐름에 초점을 맞춰라. (컨셉에서 현금까지, 고객요구에서 소프트웨어 배포까지)

   : 완전한 제품을 인도하라. (소프트웨어만이 아닌 완전한 제품을 개발하라.

                                        완전한 제품은 완전한 팀에 의해 만들어 진다.)

   : 더 높은 것을 측정하라. (주기시간으로 프로세스 역량을 측적하라. 인도된 비즈니스 가치로 팀 성능을

                                      측정하라. 순추천고객지수<NPS>로 고객만족을 측정하라.)

Ps. 린소프트웨어 개발의 적용 이라는 도서에 대한 요점이다. 요즘 정체기인 나에게 자극이 될수 있을거같다.

* 관련도서

1. 린 소프트웨어 개발의 적용
2. 린 소프트웨어 개발



 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Daily > 훈트의일상' 카테고리의 다른 글

린소프트웨어 개발 방법론  (3) 2012.02.27
나이키 신발 사이즈  (0) 2011.03.11
Dr.Dre 헤드폰  (0) 2010.12.28
와우 방문자 1만찍었...ㄷㄷㄷ  (0) 2010.11.19
토탈 5000 뿌 ㅎㅎㅎ  (0) 2010.10.02
Total 1004 기념~~  (0) 2010.08.18
posted by By훈트 2011.08.22 16:38

ASP.NET 으로 웹사이트 구축시
일반적으로 연결스트링등의 주요 변수들은 web.config 에 입력하여 사용을 한다.

그런데 web.config 파일은 보통 암호화가 되어 있지않기 때문에 누군가가 마음만 먹고 web.config 파일을
가져간다면 DB의 사용자ID, 암호, 해당IP 등의 주요정보를 가로채서 해킹시도를 할 우려가 있다.

MS에서는 이러한 web.config 에 대해 편리한 방식으로 암호화를 시켜주는 기능을 제공하고 있다.

아래의 명령어를 프롬프트창(실행에서 cmd 하면 나오는 도스창)에서 실행시켜준다
aspnet_regiis 파일을 찾을 수 없다고 나온다면

C:\windows\Microsoft.NET\Framework\v2.0.50727   로 이동한 후 아래명령을 실행해 준다.

<암호화>
aspnet_regiis -pef "connectionStrings"  [web.config가 있는 디렉토리 예) d:\MyHome]
aspnet_regiis -pef "system.web/machineKey" [web.config가 있는 디렉토리 예) d:\MyHome]


<복호화>
aspnet_regiis -pdf "connectionStrings"  [web.config가 있는 디렉토리 예) d:\MyHome]
aspnet_regiis -pdf "system.web/machineKey" [web.config가 있는 디렉토리 예) d:\MyHome]

암호화는 해당 컴퓨터의 OS에 활당되어져 있는 머신키(Machine Key) 에 의해 RSA 방식으로 생성이 된다. 그러므로 다른 컴퓨터에서는 복호화가 불가능하다. 단, 머신키에 의해 암호화 되어있는 만큼 똑같은 머신키를 복제하여 복호화 하고자 하는 컴퓨터에서 암호키를 입력해주고 복호화를 해주면 원상태의 값으로 돌아가게 된다.

덧)
나의 경우 
'RsaProtectedConfigurationProvider' 공급자를 사용하여 'connectionStrings' 섹션을 암호화하지 못했습니다. 공급자의 오류메시지 : 개체가 이미 있습니다.

와 같은 오류메시지를 받고 한참을 헤맨적이 있다. 이런 현상은 윈도7 등의 보안이 강화된 O/S 에서 나타나는듯하다(아직 더 확인된 바는 없다. 내가 지금 쓰고 있는데 윈7이라 그렇게 추측..)
이 때 cmd, 도스명령어창을 관리자권한으로 실행한 후 위의 암호화 명령을 입력하면 암호화가 성공했다는 아주 흐뭇한 메세지를 볼 수 있을 것이다,.


 


[출처] http://azbdc.tistory.com/288

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.07.04 18:16

지금 twitpic4j api를 이용해서 트위터에 사진을 올리는 부분을 디버깅중인데


겔러리에서 사진을 선택해서 올릴때 사진에 따라 OutOfMemoryError를 내며 죽는 현상이 나타났다.


모든 그림이 그런건 아니고 특정 그림만 올릴려고 하면 에러가 났다.


그림이 커봐야 고작 몇메가인데 그것땜에 에러나나 하고 용량을 확인한결과


에러나는 사진은 1.2메가 정도의 크기

 (한계점이 어느정도인지는 모르겠다)


그리고 인터넷을 검색한결과 안드로이드에도 메모리 누수 버그가 있다는 흥미로운 사실과

http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html


나말고도 이런일을 겪오 있는 사람이 또 있다는 사실을 알았따.

http://www.androidpub.com/8933


여튼 용량이 큰 이미지를 처리하려고 할때 에러가 발생 할 수 있다는 사실...


정확한 에러발생 위치는 아직 모르겠다. TwitPic4j 의 upload메소드에서 발생하는 에러이다.



대처법으로 클래스 맴버인 Bitmap 객체에 static을 붙여보라는 말도 있었지만 소용 없는듯...


그런데 문제는 공직 트위터 어플을 이용해서 사진을 올리면 잘올라간다는것이다 -_-


그렇다고 사진의 화질이 줄어들거나 그러지도 않는다. 아 어쩌면 좋지




-----

검색하다 얻은 글이다.

http://www.androidpub.com/31659

각 어플당 힙영역을 2.8메가 이하로 밖에 사용을 못하고 그이상을 사용하려고하면

OutOfMemoryError가 난다고한다. 결국 큰 이미지로 이런저런 처리를 하는 과정에서 힙영역을 많이 사용하게 된 탓인것같다. Bitmap을 byte배열로 변환하는작업이 그런것같다.


위 글에선 해결책으로 BitmapFactory.Option 클래스를 이용해서 그림파일을 메모리에 올리지 않고 너비와 높이를 구한뒤

너무 큰 그림이라고 판단되면 그림을 줄여서 OutOfMemoryError을 피하는 방법을 소개하고 있다.


BitmapFactory.Options options = new BitmapFactory.Options();
18.options.inJustDecodeBounds = true;
19.BitmapFactory.decodeFile(fileName, options);
20. 
21.return options.outHeight;


힙영역에서의 메모리 제한이기때문에 위에서 언급했던것처럼 Bitmap 변수를 static으로 하는 해결책도 틀리진 않는것같다. 다만 나의경우 Bitmap 도 그렇지만 Bitmap을 처리하는 byte

array가 있었고  (array 는 new을 해야해서 힙영역에 밖에 선언을 못할것같다.) TwitPic4J api에서 자체적으로 그림을 업로드하기위해 또 뭔가 사용하는게 있어서 용량을 초과한것 같다.


그리고 아래 주소는 Bitmap크기를 줄이는 방법과 관련된 내용이 잘설명된 포스팅 이다.

http://chiyo85.tistory.com/entry/Android-Bitmap-Object-Resizing-Tip


 
[출처] 카페인님의 블로그

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.06.30 09:48

구글 크롬에는 기본적으로 동기화 기능을 제공하고 있습니다  구글 계정만 있으면 사용이 가능하며 현재 6가지의 항목에 대해 지원을 하고 있는데 아쉽게도 탭에 대해서는 지원이 되지 않는다



TabCloud 라는 확장 프로그램은 현재 열린 탭의 저장기능을 지원한다.  
기본적으로 TabCloud 가 설치되어 있어야하고 구글계정으로 로그인을 해야한다. 확장프로그램 이름 그대로 Tab Cloud 지원이다. 어느 자리에서건 TabCloud 확장 프로그램이 설치되어 있고 자신의 구글아이디로 로그인을 하면 저장되었던 탭정보를 불러올 수 있다. 언제나 내가 보았던 페이지를 저장해서 어디서든 볼수있는 클라우드 시스템이다. 위 화면은 크롬창을 2개가 오픈되어있고 하나에는 위에보듯 15가지의 각각의 탭이 실행되어있고 디스켓모양으로 각 부라우져의 탭을 저장할수있다.


이 확장기능은 아래에서 다운 받을 수 있다.

http://bit.ly/ek3lPe 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.05.17 11:51
이클립스 설치폴더에 eclipse.ini의 설정을 바꿔보자.

안드로이드 개발에 권장되는 eclipse.ini 파일 설정값이다.

Maximum permanent generation size at the defualt of 256MB
Minimun Java Heap size -> 128MB
Maximum Java Heap size -> 512MB

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

-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vm

C:/Program Files/Java/jdk1.6.0_16/bin/javaw.exe
-vmargs
-Xms128m
-Xmx512m


[출처] 인조인간 님의 블로그 
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.05.13 13:27
안드로이드 개발을 하다가 보면 많은 어려움에 힘들어할 때가 있습니다.ㅎ

저도 그러한 많은 어려움을 겪어왔고, 오늘도 어려움에 부딪혔죠.
원래 폰 화면을 끄면 Activity는 당연히 onPause()와 onStop()이 호출되어야하는데, 이상하게 onDestroy()까지 호출되더군요..;;

한참을 찾아 헤매다가 알아낸 결과입니다.

메니페스트에서 폰 화면을 한쪽으로 지정해 둘 경우(어쩌면 가로 모드일때만의 문제일 수도 있습니다. 이 부분은 테스트해보지 않았습니다.), 화면이 꺼지면 onDestroy()가 호출되고 다시 onCreate()가 호출되어 액티비티가 새로 생성됩니다.

이렇게 가로 세로 이동 때 액티비티가 재생성되지 않도록 하려면
아래 한 줄을 메니페스트에 삽입해주면 됩니다.
(물론 액티비티 속성으로요)

android:configChanges="orientation|keyboardHidden" 


[출처] 위슈의 마법세상 
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.05.13 11:51



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
posted by By훈트 2011.05.11 15:14

[ 출처 ] 고수닷넷


고수닷넷에서 퍼 온 내용임을 밝힙니다.
 

개인 공부용으로 퍼왔습니다.

문제가 되면 쪽지 주십시요. 삭제하겠습니다.

 

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

들어가며..

VC++이나 JAVA와는 달리, 닷넷Framework에는 기본적으로 제공하는 FTP클래스가 없다.

 

이 FTP클래스를 직접 만들기 위해서는 어떻게 해야할까?

 

RFC959문서에 FTP 프로토콜 규약에 대한 설명이 잘 나와있다. 우리는 이 문서를 잘 분석해서 FTP클래스를 만들면 된다.

 

하지만, 도통 영어로만 이뤄져 있는 이 문서를 분석하기란 여간 귀찮은 일이 아닐 것이다.

 

필자는 FTP에 대해 기본적인 개념을 알고 있지만, RFC959문서를 보기는 부담스러운 개발자들에게 도움이 될 수 있도록, RFC959문서의 중요한 부분만 간추려 설명하고자 한다.

 

사실, 중요한 부분이라 함은 '명령어'라고 할 수 있다.

여기서 명령어란, FTP규약에 의거하여 서버와 클라이언트간에 주고받을 약속된 메세지를 의미한다.

 

예를 들어,

클라이언트가 서버에 접속하기 위해선 가장 먼저 사용자의 ID를 통보하기 위한,

"USER"라는 명령어를 보내고,

서버는 연결이 성공적으로 이뤄졌다는 뜻으로,

"230"이라는 메세지를 반환한다.

클라이언트는 이 230이라는 응답메세지를 받아, USER메세지가 성공적으로 이뤄진것으로 판단하여 그 다음 작업(이를테면, 비밀번호 입력)을 진행하게 된다.

 

이와 같은 형태로 이뤄지는 서버와 클라이언트간의 통신을 구현함으로써, FTP클래스를 만들어 가는 과정을 하나하나 설명해 나갈 것이다.

 

다시 말하지만, 이번에는 RFC959문서의 '명령어'부분에 대해서만 언급할 것이며, 그 외적인 부분은 실제 C#을 이용해 코딩을 해보면서, 하나하나 익혀도 문제가 없을 것으로 생각한다.

 

[목차]

1장. 클라이언트가 서버에 보내는 명령어

   (1) 서버와의 연결을 제어하는 명령어

   (2) 파일전송을 제어하는 명령어

   (3) 기타 FTP서비스를 위한 명령어

2장. 서버의 명령 수행 결과 메세지(응답메세지)

 

[클라이언트가 서버에 보내는 명령어]

 

앞으로 차근차근 구현해 나가겠지만, 닷넷으로 FTP클래스를 만들기 위해선 가장 먼저 서버와 클라이언트를 소켓을 통해 연결해야 할것이다.

연결이 되면, 먼저 클라이언트가 서버에 명령어를 보내게 되는데, 이러한 명령어에 대해 먼저 알아보도록 하겠다.

명령어 설명 중 '응답메세지'에 대한 언급이 있는데, 해당 메시지의 자세한 의미에 대해서는 다음 시간(2장)에 자세히 알아볼 것이다.

 

기본적으로, FTP를 구현하기 위해서는 명령어와 응답메세지를 송수신할 제어연결(Control Connection) (일반적으로 21번 Port를 사용)과 파일 송수신을 위한 데이터연결(Data Connection) (Port를 얻는 방식이 Active Mode와 Passive Mode 이렇게 2가지가 있음)이 필요하다.

 

이와 같은 FTP에 대한 기반지식은 이미 갖추었다고 가정하고 글을 쓰도록 할 것이다.

보다 자세한 FTP 개념에 관한 문의는 필자의 홈페이지 (http://www.ourteamz.org)를 통해 해주길 바란다.

 

(1) 서버와의 연결을 제어하는 명령어

 

[1] 사용자이름 (USER)

- 사용형식 : USER <SP> <username> <CRLF>

- 설명 : 사용자의 아이디 정보를 서버에 보낸다.

해당 FTP서버에 등록되어 있지 않는 사용자이면, 서버는 에러 응답메세지를 보내올것이다.

보통 이 명령어는 서버와 클라이언트가 연결되면, 가장 먼저 보내야 하는 명령어가 될것이다.

정상적인 수행 후, 비밀번호나 계정정보 등의 추가 정보를 요구할 수가 있으므로, 그에 따른 능동적인 대처가 필요하다.

 

[2] 비밀번호 (PASS)

- 사용형식 : PASS <SP> <password> <CRLF>

- 설명 : 보통 USER명령어 수행 직후, 비밀번호가 요구되면 이 명령어를 보내게 된다.

이 비밀번호를 단순히 string형태로 서버에 보내게 됨으로써, 다소 보안에 취약하게 된다.

서버는 이 보안에 대해 전혀 책임지지 않으므로, 클라이언트측에서 스파이웨어,키보드캡쳐 등의 해킹에 노출되어 있는 문제들을 신경써야할 것이다.

 

[3] 계정정보 (ACCT)

- 사용형식 : ACCT <SP> <account-information> <CRLF>

- 설명 : 이 명령어는 보다 자세한 사용자의 계정정보를 서버에 보내는 역할을 수행한다.

보통의 일반적인 FTP서버는 이 명령어를 요구하지 않지만, 몇몇의 경우에는 파일 전송 등에 대한 권한에 제한을 주기 위한 추가정보로써 요구되기도 한다.

일반적으로는 쓰이지 않는다고 보면 된다.

 

[4] 디렉토리 변경 (CWD)

- 사용형식 : CWD  <SP> <pathname> <CRLF>

- 설명 : DOS나 LINUX의 CD명령어와 마찬가지로 특정 디렉토리로 이동할 때 사용되는 명령어이다.

 

[5] 부모디렉토리로 변경 (CDUP)

- 사용형식 : CDUP <CRLF>

- 설명 : 상위(부모) 디렉토리로 이동할 때 사용되는 명령어이다.

이 역시 DOS나 Linux의 "CD .."와 같은 명령어를 생각하면 되겠다.

 

[6] 구조 마운트 (SMNT)

- 사용형식 : SMNT <SP> <pathname> <CRLF>

- 설명 : 다른 파일시스템 구조에 대한 마운트를 허용하도록 할 때 쓰이는 명령어이다.

 

[7] 다시 초기화 (REIN)

- 사용형식 : REIN <CRLF>

- 설명 : 사용자를 종료시키고, 입출력(I/O)와 계정정보(Account)를 Flush(일종의 초기화)한다. 또한 모든 파라미터를 리셋하지만, 서버와 클라이언트간의 Control Connection은 닫지 않는다.

이 명령어를 수행 한 후, 다시 USER명령어를 통해 로그인을 시도하면 된다.

즉, "서버에 재접속"하기 위한 명령어라고 보면 되겠다.

 

[8] 로그아웃 (QUIT)

- 사용형식 : QUIT <CRLF>

- 설명 : 사용자를 종료시키고, 파일전송이 진행중이지 않다면, Control Connection도 닫는다.

만약, 파일전송이 진행중일 경우, Control Connection을 유지한 상태에서 기다리고 해당 전송을 정상적으로 됨을 확인한 후에 연결을 끊게된다.

 

여태까지 Control Connection과 관련된 명령어를 알아보았다.

이제 파일 전송을 위한, Data Connection에 대한 명령어를 알아보자.

 

(2) 파일전송을 제어하는 명령어

 

[1] 데이터 포트 열기 (PORT)

- 사용형식 : PORT <SP> <host-port> <CRLF>

- 설명 : 실제 파일을 송수신하기 위해서는 Control Connection과는 별도로 Data Connection이 필요하며, 이 데이터연결에서 쓰일

포트를 얻기 위해 사용되는 명령어이다.

위에서 언급했던 2가지 포트를 얻는 방법 중 Active Mode에서 쓰이는 명령어이며, 간단히 말하자면, 클라이언트가 우선적으로 자신의 비어있는 Port로 연결하기를 원할 때 사용되는 방식이다.

자세한건, 앞으로 실제 이 명령어를 사용하여 FTP클래스를 구현을 해보면서 다시 설명하도록 하겠다.

 

[2] 수동으로 포트번호 얻기 (PASV)

- 사용형식 : PASV <CRLF>

- 설명 : 일반적으로는 Active Mode로 포트를 결정하지만, 방화벽등의 이유로 수동모드(Passive Mode)를 사용 해야하는 경우가 있다.

이런 경우에 서버에게 비어있는 포트를 요청하고, 서버가 알려주는 포트로 데이터연결을 하게 되는데,

즉, 서버의 빈 포트번호를 알아내기 위한 명령어라고 할 수 있겠다.

이 역시 나중에 실제 구현을 해보면서 다시 설명을 하도록 할것이다.

 

[3] 데이터 방식 (TYPE)

- 사용형식 : TYPE <SP> <type-code> <CRLF>

- 설명 : 데이터 연결(Data Connecion)를 통해 파일 목록이나 실제 파일 바이너리를 송수신하기 전에, 그 송수신하고자 하는 데이터의 타입을 결정하는 명령어이다.

ASCII, EBCDIC, BINARY(IMAGE) 등의 6가지 타입이 있으며, 일반적인 경우는 ASCII와 BINARY모드만 사용해도 충분하다.

참고로 기본값은 A와 N. 즉 ASCII + Non-print 이며, 만약, 이 TYPE명령어를 통해 포맷을 변경 할 경우, 그 설정이 직 후의 단 한번의 작업에만 유효하며, 해당 작업이 종료되면 바로 기본값으로 되돌아간다.

 

[4] 단일 파일 구조 변경 (STRU)

- 사용형식 : STRU <SP> <structure-code> <CRLF>

- 설명 : 파일 구조를 구분하기 위한 단일문자의 단위를 결정하는 명령어이며, 기본값은 File이다.

일반적으로는 사용할 필요 없다.

 

[5] 전송 방식 (MODE)

- 사용형식 : MODE <SP> <mode-code> <CRLF>

- 설명 : 데이터 전송 모드를 구분하기 위한 단일문자의 단위를 결정하는 명령어로, 일반적으로 사용할 필요 없다.

 

지금까지 파일 전송에 관한 명령어를 알아보았다.

마지막으로, 디렉토리 생성/삭제, 파일이름변경 등과 같은 기타 FTP서비스에 대한 명령어를 알아보겠다.

 

(3) 기타 FTP 서비스를 위한 명령어

 

[1] 파일수신 (RETR)

- 사용형식 : RETR <SP> <pathname> <CRLF>

- 설명 : 서버에 위치한 파일에 대해 클라이언트로 보내줄 것을 요쳥한다.

즉, 파일을 다운로드하기 위한 명령어이다.

 

[2] 파일송신 (STOR)

- 사용형식 : STOR <SP> <pathname> <CRLF>

- 설명 : 클라이언트에 위치한 파일을 서버에 보낼 것임을 알린다.

즉, 파일을 업로드 하기 위한 명령어이다.

 

[3] Unique한 파일송신 (STOU)

- 사용형식 : STOU <CRLF>

- 설명 : STOR명령어와 기본적으로 같으나, 서버 저장할 파일명을 직접 지정해주지 않고, 서버가 자동으로 유일한 파일이름을 생성하도록 할때 사용되는 명령어이다.

물론, 일반적으로는 사용할 필요없다.

 

[4] 파일송신(with create) (APPE)

- 사용형식 : APPE <SP> <pathname> <CRLF>

- 설명 : STOR명령어와 같이 서버에 파일을 업로드 하기 위해 사용되며, 이미 같은 파일이름이 존재하는 경우 파일의 끝에다가 추가하며, 그렇지 않은 경우 새로운 파일을 생성한다.

필자가 이 명령어를 직접 사용해보진 않았지만, "이어서 전송하기" 기능과는 상관없는 것으로 예상된다.

왜냐하면, 이어서 전송하기는 무조건 파일이름이 같으면 파일 끝에 갖다 추가하는 게 아니라,  전송이 중단된 특정 위치부터 전송을 해야하고, 또 그 특정위치에 부터 파일을 써야하기 때문이다.(이를 위해서는 REST명령어가 쓰인다)

즉, 이 명령어는 Log파일기록 등과 같이, 무조건 파일을 이어서(Append) 쓰고자 할 때 사용되는 명령어로 보인다.

 

[5] 할당 (ALLO)

- 사용형식 : ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF>

- 설명 : 일부 서버에서 새로운 파일을 저장할때 어떤 공간을 제한두고자 할때 사용되는 명령어로 보인다.

 

[6] 재시작-이어받기 (REST)

- 사용형식 : REST <SP> <marker> <CRLF>

- 설명 : 위의 APPE명령어에서도 언급했듯이, 이어받기/이어올리기 기능을 구현하기 위해 사용되는 명령어이며, 이 명령어로 이어받기의 경우 파일다운로드 직전, 서버에게 파일의 특정 위치부터 보내줄 것을 요청하게 되며, 이어올리기의 경우 파일업로드 직전, 서버에게 파일의 특정 위치부터 보내겠다는 것을 알리는 역할을 하게 된다.

즉, RETR과 STOR명령어가 수행되기 바로 전에 요청되게 될 것이며, 자세한건 나중에 직접 구현을 해보면서 설명하도록 하겠다.

 

[7] 이름 변경-FROM (RNFR)

- 사용형식 : RNFR <SP> <pathname> <CRLF>

- 설명 : 파일이나 디렉토리의 이름을 변경할 때 쓰이며, 아래의 RNTO명령어와 함께 사용되어야 한다.

예를 들어, 파일이름을 A에서 B로 바꾸고자 할 경우, 'RNFR A' 를 먼저 수행 한 후에 아래의 'RNTO B' 를 수행함으로써

파일이름 변경작업이 완료된다.

 

[8] 이름 변경-TO (RNTO)

- 사용형식 : RNTO <SP> <pathname> <CRLF>

- 설명 : 위의 RNFR참고 바람

 

[9] 중단 (ABOR)

- 사용형식 : ABOR <CRLF>

- 설명 : 현재의 데이터전송을 중단할 것을 서버에 알리기 위해 사용되는 명령어로, 현재 Data Connection을 통해 이뤄지고 있는

데이터의 송수신을 중단하지만, Control Connection은 정상적으로 유지된다.

만약, 현재 데이터전송이 이뤄지고 있지 않다면, 바로 226 응답메세지를 리턴하지만, 실제 데이터전송이 이뤄지고 있던 경우, 426응답메세지를 보내 비정상적으로 전송이 종료되었음을 알린뒤, 다시 226응답메세지를 리턴한다.

 

[10] 파일삭제 (DELE)

- 사용형식 : DELE <SP> <pathname> <CRLF>

- 설명 : 해당 경로에 위치한 파일을 삭제하도록 요청한다. 서버는 정말 파일을 삭제할 것인지 묻지 않고, 바로 수행한다.

 

[11] 디렉토리 제거 (RMD)

- 사용형식 : RMD  <SP> <pathname> <CRLF>

- 설명 : 디렉토리를 삭제하도록 요쳥하는 명령어로, 만약 <pathname>이 절대경로인 경우, 해당 경로에 위치한 디렉토리가 삭제되며, <pathname>이 상대경로인 경우엔 현재디렉토리(Working Directory)에 위치한 하위디렉토리가 삭제된다.

디렉토리 내부에 파일이 존재하는 경우, 디렉토리가 삭제되지 않는게 정상이다.

 

[12] 디렉토리 생성 (MKD)

- 사용형식 : MKD  <SP> <pathname> <CRLF>

- 설명 : 새로운 디렉토리를 생성도록 요쳥하는 명령어이다.

이 역시 위의 RMD명령어와 같이 <pathname>이 절대경로냐 상대경로냐에 따라 처리되는 방식이 다르다.

 

[13] 현재디렉토리 조회 (PWD)

- 사용형식 : PWD  <CRLF>

- 설명 : 현재 서버의 활성화중인 디렉토리(즉, WORKING DIRECTORY)가 무엇인지를 알아내기 위해 사용되는 명령어이다.

 

[14] LIST (LIST)

- 사용형식 : LIST [<SP> <pathname>] <CRLF>

- 설명 : 특정 경로에 존재하는 파일과 하위디렉토리들의 리스트를 요청한다.

시스템에 종속적인 정보를 보내므로, 그에 따른 유동적인 대처가 필요하다.

(예를 들어, DOS에서 DIR명령어를 사용할 떄와 LINUX에서 LS명령어를 사용할때 다른 형식의 파일리스트가 보여지는 것과 같은 원리다.)

이 명령어를 수행하기 전, TYPE명령어를 이용해서 데이터 전송 타입을 ASCII나 EBCDIC모드로 변경한 뒤, 시행해야 한다.

<pathname>을 생략하면, 현재 열려 있는 디렉토리(Working Directory)내의 정보만 가져오게 되며, 여기서 유의할점은, 필자의 경험에 의하면 <pathname>을 생략하냐 안하냐에 따라 얻어오는 파일리스트의 형식이 다소 다를 수 있으므로, 되도록 둘 중 하나만 사용할 것을 권한다. (필자는 생략해서 사용한다)

 

[15] NAME LIST (NLST)

- 사용형식 : NLST [<SP> <pathname>] <CRLF>

- 설명 : LIST명령어와 흡사하나, 파일날짜, 용량 등의 정보는 제외하고 오직 파일이름만 반환해준다.

기타 조건은 LIST명령어와 같다.

 

[16] 사이트 (SITE)

- 사용형식 : SITE <SP> <string> <CRLF>

- 설명 : 시스템에 종속적인 어떤 시스템 명령어를 수행하고자 하는 경우 사용되며, "HELP SITE" 명령어를 통해 해당 서버에서 제공하는 명령어의 방식과 구문을 알 수 있다.

즉, 현재 필자가 소개하고 있는 표준 FTP 명령어 외에 각각의 시스템에서 사용할 수 있는 명령어를 수행하고자하는 경우에 사용된다고 볼 수 있다.

 

[17] 시스템 (SYST)

- 사용형식 : SYST <CRLF>

- 설명 : 현재 접속된 서버가 어떤 OS로 이루어져 있는지에 대한 정보를 요쳥하는 명령어이다.

이를 테면, 유닉스인지 NT인지를 알려준다.

 

[18] 상태 (STAT)

- 사용형식 : STAT [<SP> <pathname>] <CRLF>

- 설명 : 현재 Control Connection 설정 상태를 알아내거나, 파일전송 중과 같이 Data Connection에서 작업이 수행되고 있는 경우, Control Connection으로 파일리스트(LIST명령어)를 얻기 위해 사용되는 명령어이다.

 

[19] 도움말 (HELP)

- 사용형식 : HELP [<SP> <string>] <CRLF>

- 설명 : FTP명령어에 대해 도움말을 보여준다.

다음시간에 자세히 알아보겠지만, 211 또는 214 응답이 오는 경우는 USER명령어를 통해 로그인을 해야만 HELP정보가 제공된다는 것을 의미한다.

 

[20] NOOP (NOOP)

- 사용형식 : NOOP <CRLF>

- 설명 : FTP서버에 접속한채로 아무일도 수행하지 않은 채 (서버에 설정된) 일정한 시간이 경과하면, 서버는 클라이언트의 연결을 종료한다.

하지만, 특정 다른 작업을 수행하지 않고도, 현재 접속을 계속 유지하기를 요청할 필요가 있는데, 이 경우에 사용되는 명령어이다.

 

 

[참고] '사용형식' 항목에서 사용된 BNF 표기법에 대한 상세설명

<username> ::= <string>

<password> ::= <string>

<account-information> ::= <string>

<string> ::= <char> | <char><string>

<char> ::= any of the 128 ASCII characters except <CR> and <LF>

<marker> ::= <pr-string>

<pr-string> ::= <pr-char> | <pr-char><pr-string>

<pr-char> ::= printable characters, any ASCII code 33 through 126

<byte-size> ::= <number>

<host-port> ::= <host-number>,<port-number>

<host-number> ::= <number>,<number>,<number>,<number>

<port-number> ::= <number>,<number>

<number> ::= any decimal integer 1 through 255

<form-code> ::= N | T | C

<type-code> ::= A [<sp> <form-code>]

                       | E [<sp> <form-code>]

                       | I

                       | L <sp> <byte-size>

<structure-code> ::= F | R | P

<mode-code> ::= S | B | C

<pathname> ::= <string>

<decimal-integer> ::= any decimal integer

 

 

정리

지금까지 FTP규약에 대해 RFC959문서(본 아티클에 첨부)에 기술되어 있는 정보 중, 가장 핵심이라 할 수 있는 "클라이언트가 서버에 보내는 명령어"에 대해 알아보았다.

 

다음시간에는 그 명령어를 받은 서버가 어떤 응답을 받아오고, 또 클라이언트는 그 응답메세지를 어떻게 처리해야하는지에 대해서 알아볼 것이다.

 

 

※ 구현환경

운영체제 : Microsoft Windows XP SP2

개발환경 : Visual Studio.NET 2003

               .NET Framework 1.1 sp1

           

※ 필자소개

박 현 웅

webdy@korea.com

http://www.ourteamz.org

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

티스토리 툴바