11월 23일 신촌의 모처에서 Adobe RIA기술에 관심이 많으신 분들과 함께, Flash Player10의 주요 기능들을 알아보고, 또 그와 관련되어 여러 생각을 나눠보는 난상토론회가 열렸습니다.

일요일이고, 추운날씨에도 불구하시고 많은 분들이 참석하셔서, 아주 유쾌한 이야기들을 많이 나눈것 같습니다.
당시 난상토론회에서 나왔던 재미난 얘기보따리들을 여러분들께 풀어놓겠습니다.

그리고 난상토론회는 여기서 끝이아닙니다! 여러분께서 댓글로, 트랙백으로 많은 의견을 보내주세요 : )

이희덕 : Flash Player 10 Feature에 이어, 난상토론회를 진행하겠다. 난상토론회는, '난상'이라는 이름 그 자체로 모든것을 엎어서 끄집어 놓고 토론하는 장이다. Flash Player 10이나, 어떤 주제에 대해서도 괜찮다. 진행하고 싶은 토론주제가 있으면 주제를 제안하시길 바란다.

패널1 : Flash Player10 에서는 필터나 이펙트를 사용할 수 있는 Pixel Bender이라는 프로그래밍 언어가 추가되었다. Pixel Bender 자체의 버전은 1.0까지 출시되었지만, 실망스러운 점이 많다. Pixel Bender의 향후 발전방안이나 사용방안에 대해서 얘기를 나누어 보고 싶다.

이희덕 : 어떤 점이 특히 실망 스러웠는가?

패널1 : Pixel Bender의 GPU가속이 지원되지 않는다는 점이 실망스러웠다. 이펙트나, 필터관련 기능들은 벤더를 쓰지 않고도, 기존의 기능들을 그대로 활용해서 구현할 수 있다.

패널3 : 솔직히 동영상의 이펙트들은 애프터 이펙트의 효과들에 동영상을 엎어서 Flash로 아웃풋 하는게 더 좋지 않은가?

패널6 : 그런데, 실제로 나도 테스트를 해봤는데, 기존의 기능들을 직접 사용하는것 보다 Pixel Bender로 포팅한 이펙트나 모션들이 상당히 부드럽게 실행되는것을 볼 수 있었다.

패널5 : 잠시, 앞서 Flash Player 10의 Feature중 3D Effects에 대해 소개한적이 있다. 그에 대해 약간 설명이 이해가 되지 않는데, 다시 설명 부탁드린다.

이희덕 : Flash Player 10에서는 Native Level에서 3D를 Draw를 할수 있도록 Z축이 추가되었다. 하지만, 완벽한 3D 구현은 불가하다. 면에 대한 3D 기능 구현은 가능하지만, Shape에 대한 3D 구현은 기존의 papervision이나 away3D를 사용하는것이 양질의 아웃풋을 얻을 수 있다.

패널5 : Shape와 면의 3D 구현 차이에 대한 자세한 설명을 부탁드린다.

패널2 : 앞서 설명한것 처럼, 3D 구현에서 입체에 대한 구현이나, 카메라뷰 변화와 같은 기능은 현재 Flash에서 기능 구현이 어렵고, 기존의 papervision이나 away3d를 사용하는것이 좋다.

패널1 : 이번 FITC 행사에서도 그에 대한 얘기가 나왔다. 이번 Flash Player10에서는 일단, papervision으로 3D를 잘 구현되게 만드는 환경의 기반을 닦는것으로 알고 있다.

이희덕 : 솔직히 나도 이번 Flash Player10의 GPU가속에 대해 실망스러운 점이 많았다. 이번 Flash Player10의 변화에 따르면 GPU가속을 위해 wmode 프로퍼티에 gpu를 쓸수 있는 옵션이 추가되었다. 하지만, 실제로 내가 테스트를 해보니, gpu가속을 켜놓으니 메모리를 많이 잡아먹고 버벅거리는것을 볼 수 있었다. CPU를 사용하는것에 비해 GPU가속이 퍼포먼스가 훨씬 낮았다.

패널3 : 그런문제들이 언제쯤 고쳐질것으로 보는가?

이희덕 : FP11이 나오는 시점이 아닐까 싶다.

패널3 : 아마 FP11이면 지금 현재 native의 3d draw에서 papervision 정도로 향상된 3D를 얻을수 있을거라 기대된다. 그리고, 얼마후면 윈도우 7처럼, 멀티 터치를 지원하는 디바이스들이 많아진다고 한다. FP10에서도 멀티터치 패치를 낸다고 하는데 이에 대해 어떻게 생각하는가?

패널1 : 마우스 클릭 이벤트를 여러 포인터에서 잡을수 있다는 건가?

패널3 : 그렇다. 이런 변화에 대해 상당히 고무적이다.

이희덕 : 하지만, 내 생각은 다르다. 예전에 이와관련된 동영상을 봤는데 실제로 창을 늘리는 동작을 할때 오른쪽 하단에서 드래그 해서 창을 늘리는게 편하지, 손가락을 이용해 죽 잡아당기는것은 상당히 불편한 절차라고 본다. 터치라는것이 일종의 직관적인 사용자 입력이라고 생각하는데, 사용자들이 통제되지 않은 환경에서 그런 불필요한 여러 동작을 해야할까 싶다.

패널3 : 하지만 MAC에서 이런 기술을 선보이고, 다양한 디바이스에서도 멀티터치를 선보인 만큼 그런 변화들은 불가피 할것으로 보인다.

이희덕 : 그럼 잠시 다른 주제로 넘어와서 진행하겠다. Flash Player10의 보안샌드 박스는 크게 두가지가 변경되었고, 그 보안샌드박스 변경으로 인한 파급력은 막대하다. 실제로 이번 보안샌드박스의 변경으로 몇몇 서비스가 정상적으로 작동되지 않는 문제까지 있었다. 이와 관련되어 어도비는 영어, 일본어등의 자료로 이전에 보안샌드박스 변화에 대해 경고했지만, 아직까지 제대로된 한국어 대응 문서가 없다. 이에 대해선 어떻게 생각하는가?

패널4 : 너무 심오한 질문아닌가 -_-;;

패널3 : 사실 한국어도비가 소극적인 활동을 하는것이 맞다. 어도비 자체내에서 한국시장에 대한 인식을 중요시 여기지 않고 있는것 같다.

이희덕 : 어도비가 한국 시장을 중요하게 생각하지 않는 이유는 무엇이라고 생각하는가?

패널3 : 아마 부진한 판매 실적이 제일 큰 영향이 있을것이다. 예전엔 농담조로 매크로미디어사의 전체 제품군 판매량 보다, 어도비의 포토샵 판매량이 월등이 높다는 얘기도 있었다.

패널1 : 예전에 한국의 플렉스 개발자 분들께서 한국어 문서 번역작업을 하신것으로 알고 있다. 그런데 어도비에서는 그런 활동에 대해 지원을 하지 않는가?

이희덕 : 내가 알기론 그 활동에 대해 어도비로부터 지원을 받지 못하는것으로 알고있다. FlexDocs의 레퍼런스 번역 작업과, toString()라는 레퍼런스 번역 작업도, 한국의 플렉스 개발자 분들께서 자발적으로 나서서 진행하고 있는것으로 알고 있다.

패널1 : 현재 Flexdocs의 번역 활동도 많이 미진해진것 같아 많이 아쉽다.

이희덕 : 그렇다. 나도 이부분에 대해 아쉽다고 생각한다. 하지만, 어도비가 한국 시장에 대한 소극적 지원에 대해 라이센스를 구매하지 않는 우리 개발자들도 반성을 해야할것으로 생각한다.

이희덕 : 이번 MAX에서 공개된것 처럼 Flex의 브랜드네이밍이, Flash Platform이라는 네이밍으로 통폐합되게 되었다. 이로 인한 클라이언트, 그리고 개발자의 인식 변화에 대해 얘기를 나눠보고 싶다.

패널3 : 잠시 질문이 있다. Flex라는게 구체적으로 어떤 변화가 있게 되는건가?

이희덕 : Flex의 브랜딩 네임이 Flash Platform으로 묶이게된다. 기존 SDK나 빌더는 별다른 변화없이 그대로 유지된다. 그런 변화의 일환으로 FDS(Flex Data Service)가 LCDS(Live Cycle Data Service)로 변화하였고, 코드네임 Thermo도 Flash Catalyst로 변화하였다.

패널3 : 그럼 Flex라는 기술이 없어진다기 보단, 브랜딩네임이 변화한다고 보는게 맞는가?

이희덕 : 그렇다. Flex라는 기술은 계속 유지될것이다. 현재도, Flex Gumbo SDK가 계속해서 보완출시되고 있다.

패널1 : 나는 이런 변화를 반기는 편이다. 많은 클라이언트들은 Flash에 대해 잘 알지만 Flex에 대해선 잘 모르고 있다. 어떤 프로젝트 진행을 제안하더라도, Flash로 설명하는쪽이 클라이언트들이 더 빠르게 알아 듣는다.

패널3 : 그런것 같다. 실제로도 Flash던 Flex던 아웃풋은 swf로 나오는것은 똑같다.

이희덕 : 이와관련된 논쟁이 최근 외국 블로그에서도 많이 일어나고 있는것으로 알고 있다. 어도비 글로벌애반젤리스트인 라이언스튜어트가 최근 이와 관련된 글을 남겼는데, 실제로 위의 토론 과정처럼, 플래시 애플리케이션이건, 플렉스 애플리케이션이건 돌아가는 런타임은 모두 플래시플레이어에서 돌아가게 되어있다. 외부 클라이언트나 개발자들도 그렇게 느낄것이다. 그렇기 때문에, 플래시플랫폼으로 통합을 가속화해야한다고 한다.

패널3 : 그렇다. 사실 플렉스가 엔터프라이즈쪽으로 최적화되어있지만, 어찌되었는 모두 플래시애플리케이션이다.

이희덕 : 외국의 360flex나, flex.org와 같은 사이트에서는 Flex의 브렌딩네임 변경에 대해 상당히 아쉬워하고있다. 그럼 클라이언트를 떠나서 개발자에게 있어 Flash Platform의 통폐합으로 인한 시너지효과는 무엇이라고 보는가?

패널1 : 사실 Flex의 SDK나 빌더는 그대로 유지가되기 떄문에 시너지효과도, 그리고 큰 변화도 없을것 같다.

패널6 : 그럼 잠시 Flash와 Flex의 차이점에 대해서 논하고 싶다. 사실 많은 Flex개발자들에게 들어오는 질문중 하나일것이라고 생각한다.

패널1 : Flex는 액션스크립트와 MXML로 이루어진 프레임워크이다. 내생각엔 Flash나 Flex나 큰 차이는 없지만, 개발향상성에서 더 많은 효율을 보여준다고 생각한다.

패널3 : Flex의 경우엔 컴포넌트 기반의 프레임워크인것 같다. 실제로, 컴포넌트 개발자도 따로있다. 이런 부분이 엔터프라이즈쪽에 특히 타켓팅이 본다고 생각한다.

패널6 : 하지만 작은 배너들을 만드는데에는 Flex가 너무 무거워서 쓰지 않고 있다. 그럼 Flash는 가벼운 사이트용도, Flex는 대기업의 엔터프라이즈 용도로 사용하는게 적당한것인가.

이희덕 : 사실 Flex가 무겁게만은 느껴지지 않는다. Flex도 튜닝하면 얼마든지 가볍게 쓸 수 있다. 예를들어서 어떤분의 경우, Flash 프로젝트인데, Flex Builder의 개발환경이 편해서, 기본적인 플래시 프레임워크들만 켜놓아서, 실제 플래시와 똑같은 용량을 내는 분도 있었다. 불필요한 라이브러리를 제거하거나, RSL을 사용한다면 Flex도 얼마든지 가볍게 사용할 수 있다.

패널1 : 그렇다. Flex는 엔터프라이즈에 최적화 되어있다기 보단, 하나의 컴포넌트 기반 프레임워크인것 같다.

이희덕 : 내 생각에도 앞서 패널1께서 설명하신것처럼, Flex 자체가 엔터프라이즈 처럼 어느 부분에 특화되어있다거나, 좀 더 무겁다기 보단, 개발 효율성을 상당히 극대화 시켜주는데 의의가 있다고 본다.

패널3 : 내생각도 그렇다. Flash의 경우 UI를 순수 AS3로 잡게되면, 상당히 고생을 하게 된다. 이점에선 Flex의 MXML이 상당히 매력적인 기술이라고 본다.

이희덕 : 또, Flex Builder은 이클립스 기반으로 개발되었다. 따라서, 기존의 svn관리등의 기능을, 이클립스 플러그인을 통해 사용할 수 있다. 그중 하나인 ant에 대해 소개하고 싶다. 보통 대규모 프로젝트에선 Flex Builder로 컴파일 하는것이 매우 느리게 된다. ant는 콘솔로 직접 컴파일하기 때문에, 매우 빨리 컴파일 할 수 있다.

패널1 : 그럼 마지막으로, MS에서는 닷넷 프레임워크를 기반으로한 실버라이트를 최근 올림픽 마케팅 등을 통해 RIA시장에서 많이 알려지게 되었다. 하지만 내가 직접 실버라이트의 SDK를 봤을때에는 실버라이트가 동영상 지원 외에는 별달리 강력한 기능이 없었다. 실버라이트에 대해 얘기를 나눠보고 싶다.

이희덕 : 그건 실버라이트1 버전때 이다. 최근 릴리즈된 실버라이트2의 기능은 상당히 강력해 졌다.

패널4 : 실버라이트의 시작은 어디서부터 였나?

이희덕 : 예전에 WPF라는 데스크탑 런타임의 상위 레벨인 WPF/E에서 부터 시작한것으로 알고 있다. WPF는 XAML과 C#으로 개발할 수 있는 프레임워크였다. 여기서 좀더 위의 레이어로 파생되어, 실버라이트, 실버라이트 모바일로 나뉘어진것으로 알고 있다.

패널1 : 솔직히 말해서 닷넷 프레임워크는 실패한 프레임워크인것 같다. 이에 대해선 어떻게 생각하는가

패널3 : 이에 대해선 부정적으로 생각한다. 닷넷프레임워크도 ASP.NET, WPF, SIlverlight등 많은 곳에서 활용되고 있다.

이희덕 : 물론 닷넷 프레임워크는 크로싱 OS를 지향하지 않는다는 점이 아쉽다. 하지만 실버라이트는 약 6MB의 플레이어 내에 닷넷 프레임워크가 내장되어 있다. 그리고, MAC나 윈도우즈 환경에서도 활용이 가능하다.

패널3 : 그렇다. 실버라이트도 현재 많은곳에서도 RIA플랫폼 관련된 개발이 진행되고 있다.

이희덕 : 나도 RIA를 사랑하고 관심있는 개발자로써 실버라이트가 충분히 매력적인 기술이라고 생각한다. 아직 부족한점이 많지만, 추후엔 Flex와 JavaFX, 실버라이트가 RIA시장에서 어깨를 나란히 하고 윈윈할수 있는 환경이 조성되길 바란다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

작년 이후로 잠시 뜸했던 기묘세미나가, 다시 개최된다는 기쁜소식 : )

특히, 이번엔 '개발자 창의력 강화 프로젝트'라는 다소 생뚱맞으면서도 뭔가 즐거운듯한 세션으로 무장해있네요.. ㅋㅋ

지난번 개수다때처럼 IBM 도곡동 군인공제회관에서 열릴 예정이라고 하네요.



저는 그날을 위해 총알을 장전하러갑니다!
여러분들도 함께해요~



등록하러가기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요 : )

정말 오랫만에 글을 남기는것 같죠? 이녀석 예전처럼 게을러진거아냐? ㅋㅋ 라고 생각하셨던 분들도 계셨을것 같은데, 사실 이런 무시무시한 경고때문에, 글을 차곡차곡써가면서 여러분께 공개는 하지 못하고 있었습니다... (흑흑)

'임금님귀는 당나귀 귀' 라고 아무리 좋고 재미있는 얘기더라도, 떠들고 다니기 좋아하는 저로써는 입이 간질간질해서 참지못할 지경이더군요... ㅠㅠ

그래도! 16일부터는 여러분들과 함께, FP10에선 어떤 API들이 추가되었고, 어떤 변화사항이 있는지, 다루어 볼수 있게되어, 매우 즐겁게 생각하고 있습니다.

앞으로도 제 블로그에 계속 연재할 예정이니, 많이 많이 찾아주세요..
(방문자 늘리기 작전인가 -_-;;)
Flash Player10이 출시된 만큼 여러분께 유익한 정보가 될수 있었으면.... 합니다!

자 그럼 오늘의 주제인 Filerefrence는 어떻게 달라졌을까요?
우선, FileReference API에 대해 소개하자면, 이 API는 로컬의 파일을 접근하고, 업로드 하거나 다운로드 하는데 사용되는 API입니다.


변경사항

Flash Player10에서 FileReference의 변경사항입니다.


일단 제일 눈에 띄는게 사용자의 로컬 파일에 접근이 가능하다?! 는 점인데, "어라? 그럼 로컬 파일들을 불러올수 있다는건가요? 어디까지 접근할수 있나요?" 라고 궁금해 하시는분들이 많으실것 같습니다. 그 내용은 아래에서 ㅋ


load(), save() 메서드

Filerefrence에는 load(), save()라는 메서드가 추가되었습니다.  두 메서드는 로컬파일에 접근하여, 파일을 읽거나 쓰는데 활용할 수 있습니다.

근데, '어? 파일을 읽고 쓰고 하면 사용자의 컴퓨터에 위해를 줄수 있지 않나요' 라고 생각하시는 분들이 많으실것 같습니다.

하지만 load(). save() 메서드의 경우 다이렉트로 호출할수 없으며, 사용자가 browse창에서 직접 파일은 선택해야 호출할수 있는 메서드 입니다.

package { import flash.net.FileReference; public class testload { private var ref:FileReference; public function testload():void { ref = new FileReference(); //FileReference에 이벤트를 걸어줍니다. (complete → 파일이 완전히 열렸을때 호출) ref.addEventListener(Event.COMPLETE, openfile); //FileReference에 이벤트를 걸어줍니다. (select → 파일이 선택되었을때 호출) ref.addEventListener(Event.SELECT, selectfile); } private function doclick():void { //파일을 불러오는 창을 띄웁니다. ref.browse(); } private function selectfile(event:Event):void { //파일을 읽어옵니다. ref.load(); } private function openfile(event:Event):void { //파일의 bytearray를 불러옵니다. //파일의 bytearray뿐 아니라, 파일의 확장자, 파일의 이름, 파일의 크기, 작성일자등도 불러올 수 있습니다. var vdata:ByteArray = event.target.data; } } }
위의 소스코드는 파일을 불러오는(load) 예입니다. 파일을 선택하고(browse), 파일을 불러오는(load) 구조로 로컬 파일에 접근할 수 있습니다.
load() 메서드의 경우 파일의 경로 지정없이 바로 메서드로 호출하게 되며, 파일의 스트림, 파일명, 파일크기등의 자료는 이벤트 데이터로 불러올 수 있습니다.

package { import flash.net.FileReference; public class testsave { private var ref:FileReference; private var savestr:String = '독도는 동해상에 위치한 대한민국의 영토입니다.'; public function testsave():void { ref = new FileReference(); } private function doclick():void { //FileReference에 이벤트를 걸어줍니다. (complete → 파일이 완전히 저장되었때 호출) ref.addEventListener(Event.COMPLETE, savefile); //FileReference에 이벤트를 걸어줍니다. (select → 파일이 선택되었을때 호출) ref.addEventListener(Event.CANCEL, cancelfile); //FileReference에 이벤트를 걸어줍니다. (ioerror → 파일저장할때 ioerror이 발생하였을때) ref.addEventListener(IOErrorEvent.IO_ERROR, onerror); //첫번째 파라미터는, 저장될 파일의 내용, 두번째 파라미터는 저장될 파일의 이름(default = null) ref.save(savestr, 'dokdo.txt'); } private function savefile(event:Event):void { trace('저장완료♥'); } private function cancelfile(event:Event):void { trace('사용자가 저장을 취소함'); } private function onerror(event:Event):void { trace('IOERROR 발생 : '+event.text); } } }
위의 소스코드는 파일을 저장하는(save) 예입니다.
save() 메서드의 경우 파라미터에 저장될 파일의 내용, 파일의 이름을 지정하게 되면, 자동으로 browse 창이 뜨게 됩니다.
한가지 주의할점은, 기존 파일에 중복해서 저장하게 될경우 ioerror가 발생하게 됩니다.


보안샌드박스

Flash Player10에서 기존 Filerefrence와, 또 새로 추가되는 매서드에 대한 보안 샌드박스가 강화되어 적용되었습니다.



따라서, 현재 UI를 HTML로 꾸며놓고, 플래시와 JS의 통신으로 파일 업로드가 구현되어있는 티스토리나, 기타 사이트들은 사용자의 직접적인 UI인터렉션으로 browse()메서드가 호출되지 않았기 때문에, 샌드박스 오류가 발생하게 됩니다.

Flash Player10이 출시된 만큼, 보안샌드박스의 변화를 빨리 파악해서, 사용자가 불편을 입지 않도록 신속히 대응하는것이 좋겠습니다.



기대분야

1. 이미지 편집기

많은 디지털 멀티미디어 기기가 보편화 되고, 또 1인미디어가 대중화됨에 따라, 웹에서 이런 멀티미디어 자료들을 손쉽게 편집할수 있는것에 대한 사용자의 요구가 날로 늘어갔습니다.

대부분의 업체는, 이를 해결하기 위해 Active X방식으로 이미지 편집기를 만들어 제공해 왔으나, Active X방식의 애플리케이션은 크로싱 플랫폼을 지원하지 않는다는 단점이 있습니다.

그래서 이를 해결하기 위해, 플래시를 통한 이미지 편집기가 스타플(http://starpl.com), 싸이월드 블로그(http://cyworld.com)에서 개발되어 사용중입니다.
 

다만, 현재까지의 flash의 Filerefrence는 파일을 선택하고, 그 파일을 업로드하거나, 다운로드 하는데에 한정되어 있었습니다.

따라서 이미지를 편집하기전 해당 이미지를 불러오기 위해, 임시 서버에 업로드 해 두고, 업로드된 주소를 플래시 상에 불러와서 작업을 해야 합니다.

이 방법의 경우, 불필요한 자원을 추가로 낭비한다는 문제점도 있지만, 최근 대부분의 멀티미디어 화상 이미지가 고 해상화 됨에 따라 파일 용량이 커지고, 또 해외지역이나 네트워크 지역이 느린 환경에선 업로드와 또 플래시에서 이미지로 불러오는데 상당한 시간 지연이 발생하게 됩니다.

하지만 Flash 10의 Filerefrence에는 load() 메서드가 추가되어 데스크탑 내의 로컬 자원에도 엑세스 할 수 있습니다. 따라서, 불필요한 자원을 낭비할 일이 줄게 되며, 또 고 해상도의 이미지를 처리하거나, 네트워크 환경이 느린 사용자에서도 지연 없이 빠르게 이미지를 불러올수 있습니다.

또, "Flash에서는 로컬 자원만 불러와 이미지 편집→서버업로드"로 프로그램의 구조적 장점도 얻을수 있습니다.


2. 대용량 파일의 안정적 전송

보통 로컬에 있는 파일을 플래시로 서버에 전송할때엔, Filerefrence의 upload는 HTTP를 통해 전송하게 됩니다.
작은 용량일 경우엔 HTTP로의 전송은 큰 무리가 없지만, 대용량 파일의 경우, 해당 서버에 과부화가 발생하거나, 중간에 연결이 끊기는 등의 문제가 발생할 수 있습니다.

그래서 대부분의 메일 서비스의 경우에도, 5mb이내의 작은 용량의 전송은 HTTP로 전송하지만, 대용량의 파일전송은 안정적인 서버와의 연결이 중요하기 때문에, Active X 컨트롤을 설치해 서버로 보내고 있습니다.

이 방법을 Flash에서 활용을 해보면 어떨까요?

이전의 Flash Player의 경우, 사용자가 파일을 선택하고, 업로드하고, 다운로드 받는등 아주 작은 부분에 대한 관여만 가능했지만, 이젠 로컬의 파일을 직접 불러와서 엑세스 할 수 있습니다.

또 Flash에서는 서버와 Socket을 주고 받을수 있는데 우리가 흔히 대용량 파일전송에 사용하는 FTP도 Socket를 통해 연결하게 됩니다.

따라서 FTP의 Socekt에 접근해서(policy-file을 설정하고, port도 1024이상으로 설정하고), 파일의 스트림을 FTP로 보내면 대용량 파일을 좀더 안정적인 전송하는게 가능하지 않을까요?


이외의 여러분들의 깜짝 놀랄만한 아이디어, 그리고 의견, 질문사항은 댓글로 남겨주세요!

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.