IFF for DDOS

얼마전(3월 11일자) 최근의 security product들이 DDOS(distributed DOS)에 대한 대책으로 counter attack을 선택하는 것에 관한 slashdot article을 읽었는데, 다음 comment들이 그야말로 예술.
 
 Can you see the tech guy trying to explain that their company was knocked off, not by the attack, but by the counter attack? “It’s okay, sir. It was friendly fire”.
 
 this is the stupidest idea i’ve heard of in a long time – if you have the network infrastructure to try and launch a DDOS attack, then you probably have the ability to survive and/or defend from DDOS attacks without resorting to insanity like this. Of course, companies in the US will probably love this, it fits well with their governments’ ‘first strike’ foreign policy directives as pushed by Mr S…
 

IFF for DDOS는 세라비군과 케케(4quake; amister; 대체 정체가 뭐냐)군과 이 주제에 대해 대화하다가 케케군이 제안한 만우절 RFC 거리. DDOS나 DDOS에 대한 counter-attack에 있어서의 위와 같은 문제점 때문에 DDOS를 수행하는 agent는 자신이 공격하고 있는 호스트(or some entity)가 공격을 의도한 호스트, 즉 적군이 맞는지 확인하는 방법이 필요하다. flight simulation에 관심있는 사람이라면 알겠지만, 이렇게 적군과 우군을 식별하는 것을 IFF(Identification Friend or Foe)라고 부른다. IFF가 보편화된다면, 당연히 IFF system을 기만하는 (즉, foe이면서 friend를 칭하는) spy agent도 생길 것도 예측해볼 수 있다.
 
DDOS에 있어서 대체로 target은 매우 좁은 범위에 한정되기 때문에, DDOS에 IFF가 실제로 필요한 경우는 매우 드물다는 생각이 들긴 하지만, 언젠가 인터넷 상의 전쟁이 벌어질 때가 온다면 DDOS외에도 IFF가 활용될 곳은 의외로 많을지도 모르는 일 아닌가 (웃음). 이를 위해서, IFF는 rules of engagement를 따르기 위한 시스템의 일부일 뿐이기 때문에, DDOS agent간의 명령 체계를 구축할 수 있는 시스템을 보완할 필요가 있을 듯 하다. 미래에는 이런 시스템들에 의해 자동화된 agent들의 대규모 전투 사례를 보게될런지도 모른다. (점점 생각이 fiction으로 흘러가고 있음)
 

IFF for DDOS 더 읽기"

Google Personalized

자신의 관심분야를 프로필에 설정하고 검색하면, 관심분야에 personalized된 검색결과를 얻을 수 있다. 사용자가 직접 관심분야를 명시하기보다는 사용자가 클릭하는 패턴에 따라, 관심분야를 자동으로 알아내도록 하면 더욱 좋지 않을까..
 
검색 하나로 참으로 여러가지를 시도해보는 구글, 부럽다!
 
http://labs.google.com/personalized/
 
@ url을 보면 알겠지만 베타 상태의 lab 서버이기 때문에 검색결과를 가져오는데 시간이 걸린다.

Google Personalized 더 읽기"

electric sheep


전세계에 분포된 클라이언트들이 계산을 수행해서 fractal animation을 그리는 스크린세이버 (SETI@Home 같은 parallel computing 소프트웨어이다). Philip K.Dick의 대표작인 ‘Do Androids Dream of Electric Sheep'(블레이드 러너의 원작)에서 따왔다고 한다. 말그대로 컴퓨터들이 꾸는 집합적 꿈인 셈.
free software, GPL. server는 library부분을 제외하고 perl로 짰다고 한다. +_+
 
http://www.electric-sheep.org/
 

electric sheep 더 읽기"

환(幻)



 
 지난 금요일 저녁, 극단 여행자의 ‘환’, 마지막 공연을 보았다. 맥베드를 각색한 작품이라는 말을 많이 들어서 사실 작품성에 의구심을 품고 갔으나, 웬걸 기대 이상의 작품이 나왔다.
 진장군(맥베드)과 묘부인(맥베드 부인)의 주인공 역도 빛났지만, 문지기의 욕에 관한 풀이와 세 무녀의 놀이가 원작과의 차별성을 집어주는 포인트였달까. 붉은 천을 뒤에 드리우고 무사들이 결투하는 장면이나, 해왕(던컨)의 살해장면도 인상이 깊었다. 축장군의 역할이 모호한 것과, 뒤로 가면서 스토리의 마무리가 약간 어설픈 것이 단점이라면 단점일까.
 플롯과 연기보다도 이 작품에서 가장 눈에 띄는 것은 의상과 음악이었다.
 화려하기도 하지만, 동양적인 절제를 함축하는 듯한 환의 의상들은 매우 아름다웠다. 결투씬에서도 진가를 발휘하는 것은 빠른 동작 하나하나를 감추는 듯 또는 드러내는 듯한 옷자락, 치맛자락이었다. 객석 뒤쪽으로부터 무대로 연결되는 통로를 통해, 이러한 의상의 효과는 극대화되었다.
 객석 오른쪽에서 공연 내내 직접 연주된 음악에서 또한, 밝고 흥겨운 축제 분위기, 다급한 액션 씬이나, 비장함을 표현하는 동양적인 악기들의 풍부함을 마음껏 즐길 수 있었다.
 
 언제 재공연을 한다면 당연히 추천해주고 싶으나, 마지막 공연이었던 것이 아쉽다. 이 공연을 추천해준 여친에게 너무너무 고마울 따름.
 
http://www.lgart.com/PerfIntro/PerfInfoRead.asp?seq=1240
http://www.yohangza.com/s_info4_1.html
 

환(幻) 더 읽기"

Memo on Engineering

Engineering이 발전하는 양상은 자연 과학이나 인문학이 발전하는 것과는 다르다. Enginering을 구분짓는 조건 중 하나는 저비용이다. 저비용을 획득하는 가장 쉬운 방법 중, 하나는 단순성(simplicity)을 달성하는 것이다.
 
단순성을 확보하는데에는 역시 다른 비용(단순성 이면의 복잡성)들이 들게된다.
주요한 것으로 생각되는 것은,
– 경험(experience; 예측 가능한 것은 단순해진다),
– 경험에서 파생되는 감각(sense; 단순성을 얻어낼 수 있는 six sense), 그리고
– 패러다임의 변환(paradigm shift; 제약받는 단순성을 해방시키기)
라고 생각된다.
 
세가지의 목표 모두 성취하기 어려운 것들이다.
하지만, 그 중 경험과 감각은 노력과 시간을 필요로 하지만,
패러다임 변환은 +alpha가 필요한 것이 아닐까. 더 고민해볼 것.
 

 
Engineering의 표면에 있는 단순성의 미학에 매료되어, 중요한 것을 보지 못하는 것은 아닌지 고민해보아야겠다. 어제 재민군의 비판에 뜨끔하여 아침에 생각난 것들을 적어보다.
 

Memo on Engineering 더 읽기"

Aspect-oriented programming: Introduction

Aspect-oriented programming: Introduction
http://portal.acm.org/citation.cfm?id=383853&coll=Portal&dl=GUIDE&CFID=18628671&CFTOKEN=48022287
 
OOP has difficulty

– localizing concerns involving global constraints and pandemic behaviors
– segregating concerns
– applying domain-specific knowledge
 
POP (Post-object programming) mechanism

– domain-specific languages
– generative programming
– generic programming
– constraint languages
– reflection and metaprogramming
– feature-oriented development
– view/viewpoints
– asynchronous message brokering
 
AOP(aspect-oriented programming)

– one important POP technology
– computer systems are better programmed by separately specifying the verious concerns of a system and some description of their relationships and then relying on mechanisms in the underlying AOP environment to weave or compose them together into a coherent program
– attempts to realize scattered converns as first-class elements and eject them horizontally from the object structure
– forcusd on mechanisms for simplifying the realization of cross-cutting converns
 
AOP vs. subprogram
 
subprogram: a concern whose code becomes tangled into other structural elements becomes a mess
AOP: aspect, weaving aspects and base code into coherent system
 
subprogram: require both knowledge and cooperation on the part of the programmers of the calling components
AOP: offer implicit invocation mechanisms for invoking behavior in code whose writer were unaware of the additional concerns
 
AOP goals
simpler system evolution, more comprehensible systems, adaptability, customizablity, and easier reuse
 
AOP issues
 
– clear-box approach
AOP can examine the program and aspect internals, producing a mixture of program and aspects
– black box approach
shroud components with aspect wrappers
 
– How an AOP system specifies aspects
– What composition mechanisms the system provides
– Implementation mechanisms
– Decoupling
– Software process
 
history of AOP
 
Karl Lieberherr (early researchers in the field)

The Law of Demeter: Objects shoud only have knowledge of closely releated objects
“Aspect-Oriented Programming with Adaptive Methods” the use of adaptive methods to avoid tangling by abstrating over the class structure
 
William Harrison and Harold Ossher

– separate specification of different class hierarchies, each implementing a concern with subsequent composition of appropriate hierarchies to build system varients (subject-oriented programming)
 
Peri Tarr

– allow multiple, simultaneous decompositions of the same software, extraction of concerns from existing software
– “Using Multidimensional Separation of Concerns to (Re)shape Evolving Software” by Ossher and Tarr
 
Mehmet Aksit and his group at Twente Univ.

– the earliest and most prominent proponents of filter-based approaches to AOP.
(In the late 1980s) filter principle was developed to express a generic data abstration mechanism)
– Bergmans and Aksit’s article “Composing Multiple Concerns Using Composition Filters”
how to embody aspects in explicit filters, by wrapping the filters around base components
 
AOP group at Xerox PARC
– the focus on crosscutting concerns is what distinguishes AOP from previous speration of concerns technologies
– developed a series of AO languages, culminating in AspectJ – “Getting Started With AspectJ”

Further Readings
 
the value of AOP technology
“Analyzing the Role of Aspects in Software Design”
“Does Aspect-Oriented Programming Work?”
 
discussions of the applications of AOP to systems development
“Structuring Operating System Aspects”
“A Layered Approach to Building Open Aspect-Oriented Systems”

the application of AOP to virtual design
“Handling Crosscutting Constraints in Domain-Specific Modeling”

an overview of using reflection techniques to implement aspects
“Aspect-Oriented Programming Using Reflection and Metaobject Protocols.”
 
Reference
 
Aspect-Oriented Software Development Web site
http://aosd.net/

Aspect-oriented programming: Introduction 더 읽기"

E-Book 관리 시스템

KeKe군과 대화中, 현재 소장하고 있는 E-Book들을 제대로 활용하기가 힘든 이유 중 하나가, E-Book들의 메타 정보가 부족하고, 검색이 힘들기 때문이라고 생각이 들었다.
그래서 구상한 E-Book 관리 시스템의 functionality들을 적어보면…
 
1) E-Book의 commit 시스템.
 
E-Book을 파일 이름을 기반으로 아마존에서 해당 ISBN을 찾아냄.
(E-Book들의 파일 이름은 일반적으로 책의 제목으로 되어있다는 가정)
이 과정에서 human intervention이 있을 수 있으나, 여러 ISBN 중 맞는 것을 선택하는 것 외의,
대부분의 작업은 자동화 가능.
 
2) ISBN을 기반으로 해당 E-Book의 (아마존에서) 메타 정보를 얻어와서 cache.
 
3) E-Book 파일과 메타 정보의 효율적인 추가/삭제.
 
4) E-Book을 검색할 수 있는 웹 인터페이스.
 
구현의 대부분은 특정 DB와 아마존 Web Service API,
E-Book의 메타정보를 나타낼 XML 정도로 가능해보인다.
 
기능들은 단순하지만, 이런 정도의 시스템만 있어도,
여러곳으로 산재되어 관리하는 E-Book들을 지인들끼리 모아서,
다른 여러가지 시너지 효과를 기대할 수 있을 듯.
 

 
언제나 불편한 것들에서 아이디어들은 많이 생각해내지만, 실제로 완전히 구현하는 일은 드물다.
(나는 기획자적인 인간인가? -_-)
대체로 GUI의 벽이 가장 크다고 볼 수 있는데, 이 벽을 깨내는 방법이 없을까. >.<
최근에는 XUL을 통해 타개할 수 없을까 고심中.
 
Amazon Web Service
http://www.amazon.com/gp/browse.html/104-5247989-7236768?node=3435361
 
 

E-Book 관리 시스템 더 읽기"