Half Close 란?

 half-closed connection 을 말하는데  TCP 특성상 양쪽에서 받고 보내는 연결이 2중이 되는데 , 한 쪽만 

닫는것을 말합니다. 종료시에 보통 입력 스트림을 살리고 전송 스트림은 닫습니다. 

When shutting down a TCP connection, something curious occurs. The TCP connection is duplex: data flows in both directions. And it's created in this manner -- it is impossible to create "half" a TCP connection, that would let data flow only from one end to the other. The SYN/ACK handshaking creates both directions at once or fails. Of course, your program might use the TCP connection to stream data in only one direction. But both directions are there...

When closing the connection, something else occurs. A party wishing to close its side of the TCP connection sends a FIN (i.e. a header with this bit set, along with any of the usual ACKs etc.). Like a SYN at the beginning of the connection, the FIN consumes a TCP sequence number, so it can be ACKed. And after the other party ACKs, the connection is half-closed! The party which sent the FIN can no longer send data -- but the other party may continue to send data.To close the TCP stream fully, both sides must send a FIN for "their" half of the connection. What possible use is a half-open connection?

In fact, a great deal of use. TCP streams share a great deal of intended functionality with UN*X pipes. In particular, it is often useful to think of sending a FIN in the same way as sending an EOF to the other side. Many processes can only compute their output after they finish reading their input. If you wish to connect such a program to a TCP stream, you'll need to denote the end of input in some manner -- and that manner is TCP's FIN.

For instance, suppose we have a program md5sum which computes the MD5 checksum of its input. md5sum reads its entire input, and only then generates output. Suppose further I have a file xyzzy on machinealice, and the program md5sum on machine bob. How can I compute the checksum?

alice% rsh bob md5sum < xyzzy

does the trick.

md5sum cannot produce any output until it knows its read all its input. Thus, no application data will flow from bob to alice until alice sends FIN. As soon as alice sends FIN, rsh on bob knows that its standard input has ended, and closes md5sum's input. Now md5sum can output its application data, which is transmitted on the half-open side of the TCP stream. Immediately following this data comes bob's FIN, closing the other half of the connection.

Without the TCP's half-close, some out of band data would have had to be used, significantly complicating TCP. A half-closed pipe is useful.

http://everything2.com/title/TCP+half-close

1. TCP/IP 에서의  Keepalive 

- 옵션이므로 설정여부는 상황에 따라 다르다.

- TCP keepalive는 setsockopt()을 사용하여 소켓 옵션(SO_KEEPALIVE)을 설정하면 사용할 수 있게 됩니다.

- 소켓 옵션이 설정되면 tcp_keepalive_interval로 지정된 시간 동안 연결이 유휴 상태가 되었을 때 keepalive 탐색 패킷을 보냅니다.

- 두 지점간에 상대방의 안부를 묻기위해 payload 가 없는 패킷을 주기적으로 보내는것이다. (지정된 시간동안 서로 패킷교환이 없을 경우에 ) 

- 그 패킷에 반응이 없으면 접속을 끊는다. 

- NAS 같은것은 중간에서 두 지점사이에 데이타 교환이 없으면 , 큐의 오래된쪽으로 이동시켜 놓는데 (결국 임의로 삭제하면 , 두 지점의 연결이 

   갑자기  끊김)  Keepalive 옵션을 통해서 꾸준히 유지중이라고 NAS 에게 알려주는 장점이 있다.

-  keepalive를 사용하는 주된 이유는 종단 시스템 중의 하나가 다운될 때 발생할 수 있는 한쪽만 열린 연결 상태를 정리하는 것입니다. 

2. HTTP 에서의  Keepalive 

- http 는 특성상 커넥션을 유지하지 않습니다. 

- 하지만 keepalive 를 설정하면 유지하게 됩니다.

- KeepAliveTimeout   5 하면 5 초동안 유지됩니다.

- 서버는 연결을 맺을수있는 소켓을 생성하는데 한계가 있습니다.

- 따라서 연결을 오래 유지하면 , 다른 사람들이 연결을 못하게됩니다.

- 하지만 사람들이 적게 접속한다면, 소수의 사람이 빠르게 인터넷을 사용할수있습니다. (리소스를 얻기위해 재 접속이 필요없으니)

- 마찬가지로 서버의 메모리 용량이 무지 크다면,  KeepAlive 설정을 해줘도 넉넉한 커넥션을 맺을수 있겠지요.

- 너무 오래 놔둘 필요는 없고 2~5초 정도면 충분할듯합니다.

3. 소켓  timeout 이란 

첫째, Connection 에서의 타임아웃

=> 연결시도를 설정한 타임아웃까지는 해봐라~ 설정시간이 지나면 그냥 포기해~ 그게 편해~~

둘째. read/write 에서의 타임아웃 

=> 한쪽이 먼일이 생기거나, 랜선이 빠졌는데도 불구하고 오매불망 기다리고있을순 없잖아.  |
     타임아웃 시간까지만 기다리고 , 그만 잊고 새 색시 찾으러 가야지~  

레퍼런스:

http://egloos.zum.com/munhwan/v/1006786

http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/Documents/Sockettimeout

위의 홀펀칭 기초 싸이트에서 핵심사항.

1. 일반적인 NAS  를 사이에둔  클라이언트 - 서버간 통신 

클라이언트가 서버 측에 UDP 메시지를 전송할 것입니다. 이 과정에서 다음과 같은 연결 통로가 구성됩니다.

서버에서 공유기로 패킷을 보내면 공유기는 60010 포트로 들어온 데이터가 수신되어야 할 내부 IP 의 컴퓨터에 대한 정보 (192.168.50.10, 50010포트)를  가지고 있으므로 정상적으로 해당 컴퓨터로 UDP 패킷을 전송할 수 있게 되는 것입니다.

2. NAS  를 사이에둔  피어 TO 피어 간 통신 

"Hole Punching"에서는 공유기의 NAT 에서 유지되는 매핑 테이블의 도움을 받아 이뤄집니다. 
아이디어는 사실 매우 간단합니다. 즉, UDP 서버가 아니라 다른 컴퓨터에서 해당 공유기 IP 의 60010 포트로 데이터
를  전송하면 어떨까 하는 것입니다.

물론, 저 상황에서는 데이터를 보낸 측이 "124.137.26.36:12000" 주소가 아니기 때문에 공유기 측에서 버려집니다. 하지만, 저렇게 데이터를 보내는 와중에 클라이언트 측이 "100.100.100.100:15000" 주소로 데이터를 한번 전송해 주면 어떻게 될까요?

공유기 매핑 테이블에는 175.194.21.14:60010 포트에 대해 2가지 원격 주소지가 포함되어 데이터를 받을 수 있게 됩니다. 결과적으로, Private IP 를 가지고 있는 PC 임에도 불구하고 마치 공용 IP 에 연결할 수 있는 것처럼 데이터를 전달받을 수 있게 된 것입니다.

http://www.bloter.net/archives/206899 펌 

와이파이얼라이언스가 무선랜과 관련된 기술들의 인증 프로그램을 강화한다. 9월18일 와이파이얼라이언스의 마케팅을 맡고 있는 켈리 데이비스 펠너 부사장은 한국을 찾아 새로 추가된 인증 프로그램과 기기 연결을 위한 무선랜의 새로운 기술을 소개했다.

와이파이얼라이언스가 그리고 있는 큰 그림은 이제 네트워크 연결을 위한 고속 통신보다는 기기들끼리 직접 연결하는 통신 기능쪽으로 방향을 틀고 있는 듯하다. 이날 소개한 내용도 기기들이 직접 통신하는 ‘와이파이 다이렉트’ 기술과 관련된 것이다.

먼저 와이파이얼라이언스가 와이파이 다이렉트 인증에 새로 포함한 4가지 기능을 살펴보자. 첫 번째는 ‘와이파이 다이렉트 전송(Wi-Fi direct send)’이다. 공유기나 핫스팟, 액세스 포인트가 없어도 기기끼리 직접 연결해 콘텐츠를 빠르고 쉽게 전송하는 기술이다. 두 번째는 ‘와이파이 다이렉트 프린트(Wi-Fi direct print)다. 스마트폰, 태블릿, PC에서 버튼 하나만 눌러 프린터에 접속하고 인쇄할 수 있게 돕는다.

DLNA도 인증에 포함된다. ‘와이파이 다이렉트 포 DLNA(Wi-Fi direct for DLNA)’다. 애초 DLNA는 같은 네트워크 안에 물려 있는 기기끼리 영상, 음악, 이미지 등의 콘텐츠 소스를 직접 전송해 스트리밍하는 기술인데 이게 네트워크로 물리는 것이 아니라 기기끼리 직접 연결하도록 강화된 것이다. TV와 스마트폰을 직접 연결해 스마트폰에 담긴 동영상을 보는 것을 떠올리면 된다.

미라캐스트는 와이파이얼라이언스가 가장 집중하는 기술 중 하나다. 스마트폰이나 PC의 화면을 그대로 디스플레이 기기에 전송하는 것으로, 여러가지 미러링 기술의 한 갈래다. 이는 이미 구글과 제휴개 안드로이드4.2부터 안드로이드의 기본으로 자리잡아 무선 디스플레이 표준 규격으로 정착하고 있다.

와이파이얼라이언스는 이 4가지 기술을 아예 기기간 직접 연결을 위한 와이파이 다이렉트 표준으로 정하고 인증 프로그램에 추가했다. 전반적으로 와이파이얼라이언스 역시 모바일을 기반으로 사물인터넷 시장의 표준 통신 규격 자리를 놓고 본격적인 경쟁에 뛰어들겠다는 심산이다. 핵심은 역시 저전력 쪽이지만 사실 와이파이는 무선 통신 규격 중에서 전력을 가장 많이 소비하는 방식이기도 하고, 부가적인 액세스 포인트 인프라도 필요하다. 그 중에서 액세스 포인트 없이 기기간에 직접 연결할 수 있는 기술을 더하고, 전력 소비의 불리함을 고속 통신이 필요한 콘텐츠로 정하는 전략이 와이파이 다이렉트 인증의 목적이다.

인증은 하드웨어 완성품으로도 받을 수 있고, 표준 규약을 지킨 칩 단위로도 받을 수 있다. 하드웨어 인증을 받으면 와이파이얼라이언스가 제공하는 런툴킷을 이용한 소프트웨어들이 하드웨어를 제어하게 된다. 데이비스 펠너 부사장은 “표준 규격이 제공되기 때문에 응용프로그램 개발자들은 API를 이용해 쉽게 네트워크에 접속하고 파일, 인쇄, 영상 등을 다룰 수 있게 된다”고 강점을 설명했다.

또 한가지 지켜볼 것은 ‘와이파이 패스포인트’다. 이건 스마트폰 같은 기기가 필요에 따라 무선랜과 셀룰러 망에 접속하는 기술을 고도화하는 것이다. 곧 선보일 ‘핫스팟2.0’ 기술에 기반해 한번 기억해 둔 기기간에는 테더링 같은 핫스팟 접속이 자동으로 이뤄지고, ‘올레 와이파이’처럼 가입해서 쓰고 있는 공공 무선랜 서비스에 대해서도 접속을 유지하는 기술이다. 일부 핫스팟들은 보안 과정 없이 네트워크에 연결하는 경우가 많은데 와이파이 패스포인트는 무조건 WPA2 방식의 보안 접속을 유도한다.

주로 모뎀 역할을 하는 스마트폰은 주머니 속에 넣어둔 채로 다른 기기들이 테더링으로 쉽게 붙여 인터넷을 쓸 수 있기 때문에 와이파이얼라이언스는 ‘인포켓 연결’이라는 단어로 설명하기도 한다. 이 기술이 잘 이뤄지면 국가간 와이파이 로밍도 쉬워진다. 이미 통신사들은 해외 사업자들과 셀룰러망 뿐 아니라 공공 무선랜에 대한 로밍 서비스를 하고 있는데 보통 이를 쓰기 위해 전용 접속 프로그램이나 미리 주어진 아이디와 비밀번호를 넣어야 한다. 이런 과정들을 없애 통신사의 가입정보를 이용해 어디에서든 무선랜을 쓸 수 있도록 하는 기술이다. 상세한 기술은 10월에 릴리즈2 규격을 통해 발표될 예정이다.

http://www.happyclass.kr/2012/09/wifi-ip-wifi.html 펌 

이전에 교실에 무선환경을 구축하는 글을 작성했다. ( http://smart-classroom.blogspot.com/2012/09/1.html 참고) 거기에 덧붙여 모바일 기기의 ip주소를 수동으로 설정하는 방법을 알아보고자 한다.

교실에 Wifi환경이 구축되었고, 집이든 어디든 Wi-fi를 사용할 때, 가끔씩 IP주소를 인증하는 과정에서 시간이 오래 걸리는 경우가 있다. DHCP서버에서 IP를 제대로 할당을 받지 못해서 이러는 경우가 많은데, 일반 가정의 wifi환경에서는 할당을 제대로 받지 못하는 경우가 작지만, 학교의 경우에는 교실의 공유기(허브)를 거쳐 학교의 게이트웨이로 가서 ip주소를 받아오기 때문에 ip주소 인증이 늦거나 실패해서 wifi연결이 안되거나 끊기는 경우가 종종 있다.

그래서 이럴때 wifi의 ip를 수동으로 지정해두면 문제없이 바로 접속이 된다. 

단, 학교나 교실에서 ip를 수동으로 사용하기 위해서는 학내망을 담당하는 담당 선생님께 비어있는 ip주소를 물어보고 써도 될지 확인을 받아두는 것이 좋을 것이다. 왜냐하면, ip가 중첩이 되면 중접된 ip를 가진 기기들이 인터넷이 제대로 작동이 안되기 때문이다.

안드로이드 기기를 기준으로 설명하겠다. 본인은 ios를 다뤄본적이 없기 때문에..... ^^;
그리고 안드로이드 기종 마다 그리고 사용하는 안드로이드 os버전마다 설정화면이 다르기 때문에 비슷하다 싶은 곳을 찾아서 설정하면 문제가 없을 것이다.


1. 시스템 설정으로 들어간다.
    (홈화면에서 홈버튼 좌측의 메뉴버튼을 누르면 팝업메뉴가 뜨고, 거기에 [시스템설정] 혹은 [Settings]이 있을 것이다.)

2. 무선 및 네트워크의 Wi-Fi로 들어간다.. 일부 기기에서는 무선AP설정 이라고 되어 있기도 한다.

3. 현재 접속되어 있는 Wi-Fi AP의 SSID 이름을 길게 누른다.

4. 그러면 아래 그림처럼 팝업화면이 뜬다. 거기에서 [네트워크설정 변경]을 터치한다.

5. [고급옵션 표시]를 체크하면 아래쪽 고급옵션이 표시가 된다. 먼저 IP설정은 [고정]으로 선택한다.

 5. 이어서 IP주소, 게이트웨이, 네트워크식별자길이(24), DNS1 을 설정한다.

ip주소와 게이트웨이 DNS는 wifi가 연결된 같은 망의 pc(교실이나 집의 pc)의 네트워크 환경에서 확인을 하고 설정을 하면 된다. ip주소는 비어있는 번호를 잘 확인해야한다는 점 잊지 말아야 할 것이다.

6. 아래쪽에 [저장]을 하고 나면 끝이다. 기본적으로 바로 설정이 바뀌는데 혹시 설정이 안바뀌어 있다면, 모바일기기의 Wifi를 껐다가 다시 켜면 설정대로 연결이 될 것이다.

이렇게 ip주소를 수동으로 설정해두면, ip인증에서 ip주소를 할당받는 과정이 생략되어 접속시간이 빠르고, 안정적인 접속이 이루어지게 된다. 단, 주의할 점은 같은 네트워크환경에서 사용중인 ip주소를 사용하지 않도록 조심만 하면 된다.

http://kenial.tistory.com/839  

#. 
오늘날 프로그래머가 다루는 기술 분야는 매우 다양하고, 실제 프로그래밍에 있어서 프로그래머가 저수준(수준이 낮다는 뜻이 아니라, 추상화가 덜 되었다는 의미로)의 기술 주제를 다루는 일도 드문 일이 되었다. 네트워크 프로그래밍의 경우에도 마찬가지여서 인터넷을 통해 데이터를 주고받거나 하는 작업에 소켓을 직접 사용해서 프로그래밍하는 경우는 흔치 않은 일이 되었고, HTTP 기반으로 하는 네트워크 프로그래밍이 유행하게 되었다. HTTP를 통한 네트워크 프로그래밍은 이해하기 쉽고, 이러한 프로그래밍 작업을 쉽게 해 주는 라이브러리 또한 도처에 널려 있는 것을 볼 수 있다.  

그러다보니 TCP니 UDP니 하는 것을 다룰 일도 거의 없어졌고, 요즘에는 대부분의 응용 프로그래머가 네트워크에서의 데이터의 전송은 두 개의 특정 호스트가 1:1로 통신하는 것(=유니캐스트Unicast)이 기본적인 것이라고 인식하고 있는 것 같다. 그렇지만 이러한 1:1 통신은 TCP 프로토콜의 특징이며, 이는 HTTP 프로토콜이 TCP 프로토콜을 기반으로 하고 있기 때문에 TCP 프로토콜과 마찬가지의 특징을 갖고 있는 것 뿐이다. 

혹시라도 UDP 프로토콜을 아직 다뤄보지 못한 프로그래머를 위해서 짧게 설명하자면, UDP에서는 유니캐스트 외에도 멀티캐스트(Multicast)와 브로드캐스트(Broadcast) 기능을 제공한다. 이는 그림으로 나타내면 다음과 같다:

멀티캐스트,  브로드캐스트

멀티캐스트는 자신이 접속한 네트워크 내의 여러 호스트에게 패킷을 전송하는 것이고, 브로드캐스트는 자신이 접속한 네트워크 내의 모든 호스트에게 패킷을 전송하는 것이다. (이 글에서는 브로드캐스트를 다루고 있는데, 특별한 이유가 있어서기보다는 ... 멀티캐스트보다 브로드캐스트가 간단하기 때문이다) 

실제 브로드캐스트로 UDP 패킷을 전송하기 위해서 유니캐스트와 다르게 작업해야 할 부분은 별로 없으며, 패킷을 전송할 IP 주소만 올바로 지정하면 된다. 단순한 상황을 하나 가정해보자. 만약 무선 공유기를 사용하고 있고, 무선 공유기에서 할당받은 IP가 192.168.0.4라고 가정하면, 단순히 192.168.0.255라는 IP 주소를 목적지로 UDP 패킷을 송신하면 된다. 그러면 위에 보인 브로드캐스트의 그림처럼, 해당 무선 공유기에 연결되어 있는 모든 네트워크 기기에 UDP 패킷이 전달된다. 


#. 
이러한 브로드캐스트는 개념만 알고 있다면 상당히 많은 부분에 응용할 수 있다. 게임을 예로 든다면, 브로드캐스팅을 통해 자신의 데이터를 자신이 접속한 네트워크의 모든 호스트에 전송함으로써, 상대방의 IP를 몰라도 게임을 실행한 호스트를 찾아내는 기능을 구현할 수 있다. (스타크래프트의 멀티플레이 게임을 생각해 보자) 필자는 개인적으로 이러한 "발견Discovery" 기능을 UDP의 가장 강력한 특징 중의 하나라고 생각하고 있다. 

물론 이러한 UDP의 특징을 응용한 프로토콜이 없는 것은 아니다. 대표적인 것으로 애플의 Bonjour 같은 것이 있다. 

 

애플 홈페이지의 Bonjour 기술 문서를 읽어보면, IP 네트워크에서 서비스를 공개/발견(Publish/Discovery)하기 위한 용도로 사용할 수 있다고 나와 있다. (자세한 내용은http://en.wikipedia.org/wiki/Bonjour_(software)을 참고하자) 



#. 
최근까지 필자는 UDP의 이러한 특징을 활용한 프로그램을 만들어오고 있다. 하나는 미디어를 로컬 네트워크에서 배포/구독할 수 있는 솔루션이며(Mug 서비스라고 이름붙였다), 또 하나는 로컬 네트워크를 통해 서로 동기화가 가능한 모바일용 야광봉/전광판 앱이다. (이 블로그 글을 읽고 있다면 이미 알고 있겠지만, BITNA라는 이름을 갖고 있다) 

이 프로그램들의 초기 구조를 설계하는 단계에서, 어쨌든 데이터를 서로 주고받아야 하는 네트워크 프로그램이다보니 자체 프로토콜을 설계하는 작업이 필요했다. BITNA 앱의 경우 처음에는 자체 프로토콜(이라기보다는 패킷의 데이터 구조)을 설계하여 적용했었지만, 얼마 못가 이런 저런 문제가 많다는 것을 알게 되었다. 가장 두드러진 문제는 프로토콜 설계 자체의 유연성이었는데, 프로토콜에 기능을 추가하기 위해서 데이터를 추가하면 추가된 패킷 구조에 따른 처리 로직을 계속해서 재검토해야하는 상황이 반복되었다. 

위에서 이야기한 Bonjour를 사용할까 하는 생각도 있었으나, 필자가 만드는 프로그램은 멀티 플랫폼을 지향하고 있었다. Bonjour는 오픈소스이고 윈도우나 리눅스용 SDK도 제공되지만, 맥을 제외하면 Bonjour 서비스 자체는 따로 설치해야만 했다. (만약 대상 플랫폼이 맥/iOS 전용이라면 Bonjour도 나쁘진 않다) 그러다보니 차라리 좀 더 단순하고 멍청한(Simple & Stupid, ‘이해하기 쉬운’이란 의미로 받아들이자) 라이브러리를 만들어 보자는 생각이 들었다. HTTP 프로토콜처럼 쉽게 사용할 수 있는 UDP 기반의 프로토콜을 설계해서 적용하면 어떨까? 

사실 HTTP 프로토콜도 사양서를 읽어보면 알겠지만, 프로토콜을 직접 다루기는 그렇게 쉽지 않다. 그냥 그렇다 치고 넘어가자...

#. 
이쯤에서 먼저 필자가 만든 라이브러리의 프로젝트 이름을 알려두자면(사실 만든 지 이미 꽤 됐고, 이 글은 이 라이브러리를 외부에 알리기 위한 글이다!), Fountain 프로젝트라는 이름을 갖고 있다. 프로토콜은 Fountain 프로토콜이라고 부르고 있다. 이와 관련해서 이전에 Fountain Project와 Mug를 공개합니다라는 글을 쓴 적도 있으니, 필요하다면 참고하도록 하자. 

어쨌든, 프로토콜로 다시 돌아와보자. 위에서는 HTTP를 언급하였는데, HTTP는 프로토콜 자체의 명세를 제외하고 통신에 필요한 규약만 놓고 본다면 다음과 같은 특징을 갖고 있다: 

• TCP 프로토콜이다.
• 80 포트를 통해 HTTP 요청을 처리한다.
• 텍스트에 기반을 두고 있다.

 
마찬가지 방식으로, Fountain 프로토콜은 다음과 같은 특징을 갖고 있다:

• UDP 프로토콜이다. (UDP에 기반하므로 요청/응답이라는 구조는 별도로 존재하지 않는다)
• 7904 포트를 통해 Fountain 메시지를 처리한다. 
• JSON 포맷의 텍스트에 기반을 두고 있다.

Fountain 메시지의 예는 다음과 같다 (이전에 JSON을 다뤄본 적이 있다면 익숙할 것이다) :  

{"FM":{"TEST":{"PacketIndex":1,"Base64Data":"","Checksum":237}}}

• "FM"은 Fountain 메시지임을 식별하기 위해 사용한다.
• "TEST"는 Fountain 메시지를 사용하는 서비스의 식별자이다. 예를 들어, 필자가 만든 Mug 서비스의 경우에는 식별자로 "MLST"를 사용하고 있으며, BITNA 앱은 식별자로 "aBIT"을 사용하고 있다.
• 서비스 식별자 내부에는 개발자가 원하는 대로 JSON 포맷에 맞게 메시지 내용을 정의하여 사용하면 된다.

실제 프로그램을 구현하는데 있어서는 몇 가지 유의할 점이 더 있긴 하지만, 기본적인 구현에 필요한 사항은 위와 같다. 이런 방식으로 프로그램마다 다른 종류의 프로그램/서비스와 식별자가 중복되지 않도록 각자의 Fountain 메시지를 설계하여 사용하면, 얼마든지 7904 포트를 열어 필요한 메시지를 수신하여 처리할 수 있다. 



#. 
이 Fountain 라이브러리(일단은 이렇게 불러야 할 것 같다)는 현재 Objective-c, Java, C# 등으로 구현되어 있다. 딱히 이들 언어가 좋아서라기보다는 아이폰, 안드로이드, 윈도우 폰용 BITNA 버전을 만들다 보니 각 플랫폼 별로 구현이 된 것인데, 아직 다른 오픈 소스와 얽혀 있는 부분도 있고 해서 당장 오픈할 수는 없을 것 같다. 앞으로 어느 정도 정리되고 나면 BitBucket이나 GitHub를 통해 오픈 소스로 공개할 예정이다. 

혹시 그 이전에라도 관심 있는 개발자가 있다면, 연락 주시길. 성심 성의껏 응대하도록 하겠다 : )