엔터프라이즈 애플리케이션에서 보안은 필수적인 요소이다. 이번 호에서는 플래시의 보안 이슈와 XML 웹 서비스를 이용하는 또 다른 강력한 방법인 플래시 리모팅에 대해 살펴본다.
지난 호에서 우리는 플래시에서 XML을 어떻게 다루고 XML 통신을 어떻게 하는지에 대해 살펴봤다. 하지만 간편하면서도 훨씬 강력한 방법이 제공되는데 그것이 바로 ‘플래시 리모팅(Flash Remoting)’이다.
플래시 리모팅은 주로 XML 웹 서비스를 이용하기 위해 玲淪舊嗤? 닷넷 리모팅(.NET Remoting)이나 자바 RMI와 비슷하다. 즉, 리모팅을 통해 원격(서버 사이드)에 있는 메쏘드를 호출할 수 있다. 내부적으로는 SWF(플래시 플레이어에서 수행되는 플래시 파일을 가리킴)의 통신 기능을 플래시 리모팅 컴포넌트를 통해 확장한 것으로, 통신 프로토콜 자체는 플래시의 고유한 방법으로 구현되어 있다.
 |
| <그림 1> 플래시 리모팅 개념 |
플래시 리모팅
플래시 리모팅은 SOAP 기반의 웹 서비스를 통합하기 위한 서버측 도구(실제로 웹 서버용 필터로 동작한다)이다(<그림 1> 참조). 콜드퓨전 MX, 닷넷, 자바 버전이 각각 따로 있으며, EJB 구축된 서비스, 닷넷 서버, 콜드퓨전 등으로 구축된 웹 서비스를 플래시에서 그대로 이용할 수 있도록 하기 때문에 웹 서비스를 이용하는 플래시 애플리케이션을 쉽게 구축할 수 있다. 즉, 비즈니스 로직은 서버측에 웹 서비스로 구축하고 클라이언트측 UI 플래시로 개발하려는 경우에 가장 좋다고 할 수 있다. 서버측 개발자는 ‘Flash Remoting MX’를 설치하는 것 외에 추가적인 코드를 작성해야 하는 일은 없다.
ASP.NET 웹 서비스를 만들고 플래시에서 이 웹 서비스를 호출하는 과정을 간단하게 살펴보자. ASP.NET 서버측에 ‘Flash Remoting MX for Microsoft .NET’이 설치되어 있어야 한다(Flash Remoting MX는 상용 제품이지만, 매크로미디어 사이트에서 평가판을 받아 충분히 테스트해 볼 수 있다). 일반적으로 다음 폴더에 설치된다.
C:\Inetpub\wwwroot\flashremoting
플래시 리모팅을 사용하는 클라이언트 SWF를 개발하기 위해서는 플래시에 리모팅 컴포넌트(Flash Remoting Components)를 설치해야 한다(혼돈하지 말아야 한다. Remoting MX는 서버측에 설치되는 요소이며, 자바, 닷넷, 콜드퓨전 등의 버전이 따로 있다. Remoting 컴포넌트는 플래시에 추가로 설치되는 플래시 클라이언트 개발용 컴포넌트이다). 리모팅 컴포넌트가 설치되면 <화면 1>처럼 ‘Remoting’이란 컴포넌트가 설치되고, 이하에 ‘NetServices’등의 객체가 생기는 것을 볼 수 있다.
 |
| <화면 1> 플래시 리모팅 컴포넌트 설치 확인 |
먼저 ASP.NET으로 간단한 웹 서비스를 만들어 보자. 비주얼 스튜디오 닷넷을 시작하고 ‘HelloFlash’란 이름으로 웹 서비스 프로젝트를 만든다(<화면 2> 참조). 그리고, HelloWorld 메쏘드의 주석을 제거해 빌드한다. <리스트 1>처럼 가장 간단한 웹 서비스를 만들고 다음과 같이 WSDL을 확인해 보자.
http://localhost/HelloFlash/Service1.asmx?WSDL
이 WSDL은 HelloFlash 프로젝트에서 노출되는 웹 서비스에 대한 설명을 담고 있다(플래시측에서 이 WSDL이 사용된다).
 |
| <화면 2> 웹 서비스 프로젝트 만들기 |
|
<리스트 1> Hello World 웹 서비스 | |
| |
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
namespace HelloFlash
{
public class Service1 : System.Web.Services.WebService
{
public Service1()
{
InitializeComponent();
}
[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
}
}
| |
 |
이제 다음과 같은 수순으로 작업해 HelloFlash 폴더를 플래시 리모팅이 가능하도록 준비를 한다.
1 플래시 리모팅 폴더(flashremoting)에 있는 flashgateway.dll 파일을 HelloFlash/bin 폴더에 복사한다.
2 HelloFlash 폴더 등록정보에서 보안 탭을 누르고, ASPNET 계정을 추가하고 쓰기(Write) 권한을 추가한다.
3 빈 apsx 페이지를 만든다(여기서는 default.aspx 페이지를 만들었다).
4 web.config에 다음의 내용을 추가한다.
<httpModules>
<add name="GatewayController"
type="FlashGateway.Controller.GatewayController,flashgateway"/>
</httpModules>
HelloFlash 폴더가 플래시 리모팅에 사용될 수 있게 준비됐다. 이제 플래시를 시작하고, 첫 프레임에 <리스트 2>와 같이 액션스크립트를 작성한다. getService() 메쏘드는 ‘http://localhost/HelloFlash/Service1.asmx?wsdl’에 기술된 WSDL 내용을 가지고 프록시 객체를 생성한다. 생성된 serv 객체를 통해 다음과 같이 메쏘드를 호출할 수 있다.
serv.HelloWorld();
웹 메쏘드를 호출하면 “메쏘드 이름_Result()”, “메쏘드 이름_Status()”의 콜백이 호출된다. 이 콜백을 통해 리턴 값을 얻을 수 있다.
function HelloWorld_Result(result)
{
trace( result );
}
수행 결과는 “Hello, World”라고 출력되지만 XML 웹 서비스를 간단한 액션스크립트 코드로 이용할 수 있다는 점에서 리모팅은 무척 강력한 방법이 된다(ATL/COM으로 어렵게 액티브X 컨트롤을 구현하는 것에 비해 훨씬 적은 비용으로 빠르게 클라이언트를 개발할 수 있다).
|
<리스트 2> XML 웹 서비스를 호출하는 액션스크립트 | |
| |
#include "NetServices.as"
#include "NetDebug.as"
if (inited == null)
{
inited = true;
NetServices.setDefaultGatewayURL("http://localhost/HelloFlash/default.aspx")
gateway = NetServices.createGatewayConnection();
serv = gateway.getService("http://localhost/HelloFlash/Service1.asmx?wsdl", this);
}
serv.HelloWorld();
function HelloWorld_Result(result)
{
trace( result );
}
function HelloWorld_Status(result)
{
trace( error.descript-xion );
trace( result );
}
| |
|
날씨, 증권, 상품 조회 등 변화하는 데이터를 조회하거나 서버와 상호작용을 하는 서비스를 구성할 때 플래시 리모팅은 매우 유연하면서도 강력한 방법이 된다. 플래시 리모팅은 ADO와 연결되어 서버 측의 데이터를 처리하거나 서버 측의 어셈블리를 호출할 수 있다. 이런 기능도 웹 서비스를 이용하는 것 못지않게 다양한 응용이 가능하게 한다.
플래시 보안 : SWF는 HTML이나 자바스크립트와 다르지 않다?
엔터프라이즈 애플리케이션에서 보안은 빼놓을 수 없는 이야기이다. 애플리케이션이 공개적으로 배포되는 인터넷 환경에서는 더더욱 그렇다. 플래시 관련 보안 이슈 중 가장 먼저 떠오르는 것이 바로 SWF 디컴파일러(decompiler) - SWF 파일에서 리소스와 액션스크립트를 추출하는 도구에 대한 것이다.
<화면 3>은 대표적인 SWF 디컴파일러(Sothink)의 수행 화면이다. 리소스는 물론 액션스크립트를 완벽하게 디컴파일한다. 보안의 관점에서 볼 때 SWF는 HTML이나 자바스크립트와 다르지 않다. 액션스크립트를 포함해 SWF가 가지고 있는 내용은 모두 분해되고 해체될 수 있다. SWF 파일 포맷이 공개되어 있기 때문인데, 원천적으로 이를 방지할 방법은 없다(반면에 FLA 파일은 포맷이 공개되어 있지 않기 때문에 SWF를 FLA로 디컴파일해 주는 도구는 없다).
 |
| <화면 3> SWF 디컴파일러 수행 화면 |
일단, 플래시 개발자 입장에서 볼 때 애써 작성해 놓은 코드나 리소스가 노출된다는 측면에서 매우 안타까울 수 있다. 플래시 전문가들은 자신의 코드를 보호하고자 할 경우 무비클립을 나누어 동적으로 로드하도록 권고하고 있지만, 이 방법 또한 디컴파일을 어렵게 할 뿐 디컴파일 자체를 원천적으로 막을 수는 없다.
이보다 더 문제가 되는 것은 액션스크립트에 포함되어 있는 로직이나 데이터가 노출된다는 점이다. 서버에서 인증을 받는 SWF나 서버와 상호 작용을 하는 게임을 플래시로 제작할 때는 반드시 이런 점을 고려해야 한다(서버와 통신하는 프로토콜이 모두 노출된다). SWF 안에 중요한 데이터나 패스워드 같은 내용을 넣어서는 안 된다. 이 글에서 설명하고 있는 플래시 통신의 다양한 방법들이 중요한 이유 중 하나가 여기에 있다. 즉, 중요한 알고리즘은 서버에 구현함으로서 악의적인 공격에 대비해야 하며, 프로토콜 노출을 고려해 서버를 안전하게 보호할 방법을 마련해야 한다.
플래시 통신 보안과 SSL
우리가 사용하는 인터넷 상의 통신은 엽서와 같다. 즉, 엽서가 지나는 길에 있다면 누구나 엽서에 쓰여진 내용을 볼 수 있다. HTML이나 SWF, 메일 모두 마찬가지이다(심지어 대부분의 인터넷 사이트에서 입력하는 아이디와 패스워드도 전혀 암호화되지 않은 채 돌아다닌다). 서버와 클라이언트 사이에서 누군가 마음만 먹으면 손쉽게 데이터를 볼 수 있다. 이 문제를 해결하는 것이 SSL(Secure Socket Layer)이다. SSL은 별도의 추가적인 개발 없이 완전한 보안을 구현한다(즉, 보내는 측과 받는 측 사이에서 데이터를 중간에 볼 수 있다 하더라도 전혀 해독할 수 없다).
플래시는 HTTPS(HTTP + SSL)를 지원한다. 사실 플래시 자체가 SSL을 지원한다기보다는 브라우저가 제공하는 SSL을 이용한다고 하는 편이 맞을 것이다. 여러분이 SSL이 적용된 웹 페이지에서 SWF를 받았다면 그것은 SWF와 데이터 전체가 암호화돼 전송됐음을 의미한다. 주의할 것은 SWF가 전송 중에는 암호화된다는 점이다. 즉, SWF 디컴파일을 막는 것과 SSL은 아무런 상관이 없다.
SSL은 가장 안전한 통신 보안 방법이다. 대부분의 브라우저가 128비트 SSL 암호화를 제공하고 있어 충분히 안전하다고 할 수 있다. 웹 서버인 IIS(Internet Information Server)가 HTTPS를 사용하게 하려면 <화면 4>와 같이 공인 인증기관으로부터 공인 인증서를 받아서 IIS에 설치하고, <화면 5>처럼 SSL을 사용하도록 설정하면 된다(SSL 설정은 이 글의 범위를 벗어나므로 자세한 방법은 베리사인과 같은 공인 인증기관 사이트를 참고하라).
 |
| <화면 4> IIS에 서버 인증서 설치 |
 |
| <화면 5> IIS에 128비트 SSL 설정 |
플래시 암호화 통신
SSL을 사용할 수 없을 때 최소한 데이터를 암호화해 보내야 한다. 인증(authentication) 과정을 예로 들어 살펴보자. 패스워드와 같이 중요한 데이터를 그대로 전송해서는 안 된다. <화면 6>은 MD5를 구현한 예이다. 해시는 데이터 전체를 암호화하는 것은 아니지만 암호화된 결과를 가지고 원본을 알 수 없다는 단방향성을 가지고 있어 인증에 많이 사용된다(소스는 ‘이달의 디스켓’에 포함되어 있다).
 |
| <화면 6> MD5 해시 구현 예 |
해시 방법을 이용해 다음과 같이 인증을 할 수 있다. 이 방법의 핵심은 실제 패스워드를 보내지 않는다는 것이다.
1 SWF는 서버에 임의의 문자열 S을 요청한다.
2 SWF는 수신된 S에 사용자가 입력한 패스워드를 붙여서 해시 암호화해 문자열 A를 생성한다.
3 A를 서버로 전송한다.
4 서버는 SWF로 보낸 S와 데이터베이스에서 얻은 사용자 패스워드를 붙여서 해시화해 B를 생성한다.
5 서버는 A와 B가 일치하는지 여부를 확인한다.
플래시로 제작된 네트워크 게임이 있다고 하자. SWF가 디컴파일된다면 서버와 통신하는 프로토콜이 모두 공개될 것이다. 이 때문에 게임 서버가 해킹된다면 이것은 엄청난 일을 야기한다. 따라서 플래시 암호화가 필요하다. 다시 말해, 프로토콜이 노출되더라도 안전하게 통신할 방법을 마련해야 하는데 바로 해시 암호화와 같은 방법이다. 예를 들어, 서버로부터 특정한 키를 발급받아 항상 해당 키로 암호화된 데이터를 주고받는다면, 클라이언트 암호와 알고리즘과 로직을 알더라도 서버측에 있는 로직을 알아내지 못하게 되어 게임을 해킹하기 힘들어진다.
다음은 SHA1 알고리즘을 테스트하는 액션스크립트이다. MD5 해시보다 SHA1 알고리즘이 훨씬 안전한 것으로 알려져 있다(MD5 알고리즘과 SHA1 알고리즘을 구현한 액션스크립트는 ‘이달의 디스켓’에 포함되어 있으며, 참고자료를 통해서도 얻을 수 있다).
#include "sha1.as"
trace(b64_sha1("Hello, World"));
앞의 수행 결과는 다음과 같다.
kH0U+zrysNTxjC1Gq+iu3OFzZ70
앞의 액션스크립트와 <리스트 3>의 C# 코드의 수행 결과는 똑같다. 이 결과를 이용해 앞서 설명한 인증을 구현할 수 있다. 사실 여기에는 좀더 개선된 방법이 필요하다. 예를 들어, 사전(dictionary)에 의한 공격을 막기 위해 암호화 데이터에 salt를 추가하거나 해시를 두 번 통과하게 하는 방법도 좋은 개선 방법이다.
|
<리스트 3> C# SHA1 알고리즘 구현 코드 | |
| |
using System;
using System.Text;
using System.Security.Cryptography;
class TestSha1
{
static void Main(string[] args)
{
string plainText = "Hello, World";
// SHA1 해시
UTF8Encoding u8e = new UTF8Encoding();
byte[] byteBuffer = u8e.GetBytes(plainText);
SHA1 sha = new SHA1CryptoServiceProvider();
byte[] result = sha.ComputeHash(byteBuffer);
// 해시 값을 base64 문자열로 변환해 출력
Console.WriteLine( Convert.ToBase64String( result ) );
}
}
| |
|
다른 보안 이슈
다운로드된 SWF가 다른 서버(도메인)와 통신을 하는 것은 악의적으로 사용될 가능성이 있어서 이를 못하게 막고 있다(이것은 자바 애플릿도 마찬가지다). 이것을 교차 사이트 공격(Cross-Site Attack) 방지라고 하는데, SWF는 다운로드된 서버의 도메인 안에 있는 서버와 통신이 가능하다. 예를 들어, www.elasticware.com에서 SWF가 다운로드됐다면 SWF는 content.elasticware.com과 통신이 가능하다(즉, 자신이 다운로드된 서버 및 같은 도메인에 있는 서버와 통신이 가능하다).
플래시는 사용자의 파일 시스템, 카메라, 마이크로 폰에 접근이 가능하다. 접근 가능 여부는 사용자 설정에 따른다. 사용자의 파일 시스템에 접근은 독립적인 SWF 단위로 제한된다. 일반적으로 설정 정보나 상태 정보를 저장하는 목적으로 사용되며, 기본 저장 공간은 100K이다. 사용자가 크기를 설정할 수 있고(<화면 7> 참조), 저장소의 크기와 쿠키 저장 여부에 대한 것은 브라우저 설정과 무관하다.
 |
| <화면 7> 플래시 설정 저장 공간 |
클라이언트에 데이터를 저장하는 방법으로 액션스크립트에서 SharedObject 객체를 사용한다. 다음은 SharedObject를 사용해 클라이언트에 카운터를 저장하고 로드될 때마다 증가시키는 예이다.
sObject = SharedObject.getLocal("counter"); // 읽기
if( sObject != null )
{
sObject.data.counter++; // 연산
_root.savedata = sObject.data.counter;
sObject.flush(); // 저장
trace(sObject.data.counter);
}
SWF에서 저장한 내용은 다음 폴더에 저장되는데, 각 SWF마다 그리고 SharedObject에서 저장하는 객체 이름으로 내용을 담은 파일이 생성된다.
C:\Documents and Settings\Administrator\Application Data\Macromedia\Flash Player
플래시 보안의 핵심은 SSL과 동적인 서버 사이드 연결로 요약할 수 있다. 즉, 통신 보안을 위해 가능한 SSL을 사용하고, 액션스크립트가 완전히 노출된다는 가정하에 중요한 로직은 서버측에 구현하고 데이터를 암호화하는 별도의 로직을 클라이언트와 서버에 따로 구현하는 것을 추천한다.
‘Flash.NET’의 가능성
지금까지 3회에 거쳐 서버측(ASP.NET)과 플래시(SWF) 사이의 다양한 통신 방법과 개발 이슈들에 대해 살펴봤다. 플래시는 리치 클라이언트의 가능성뿐만 아니라 사실상의 플랫폼 독립성을 갖추고 있고, 높은 생산성을 가지고 있는 훌륭한 클라이언트 개발 도구이다. 플래시와 닷넷의 만남은 유연하고 고 가용성의 시스템을 구축하는 데 손색이 없으며, 특히 XML 웹 서비스의 활용은 생산성을 높이는 아주 좋은 방법이다.
다만, 그 활용의 장벽은 ASP.NET 개발자는 플래시를 모르고, 플래시 디자이너는 ASP.NET에 익숙하지 않은 기술간의 문턱이라고 할 수 있다. 예를 들어, 데이터와 비즈니스 로직을 SWF에 두지 않는 것만으로도 훨씬 유연한 개발을 할 수 있다. 비주얼 베이직과 C++, J2EE와 닷넷, 호스트와 유닉스 그리고 유닉스와 NT처럼 기술과 기술 사이의 다리가 되는 기술이 훨씬 중요할 때가 많다. 1+1이 2 이상이 될 수 있듯이 플래시(Flash)+닷넷(.NET) 역시 Flash.NET 그 이상이 될 것이다. @
올해 3월 닷넷 정식 버전이 발표되면서 C#이 새로운 언어로 떠오르고 있는데, 특히 네트워크 부분에서 기존의 IOCP(IO Completion Port) 기능을 손쉽게 사용할 수 있도록 만들어 놓았다는 점에서 주목할만 하다.
기존에는 이 기능을 이용하려면 Win sock 2 API를 직접 호출해야 했지만, C#에서는 이 기능이 BCL (Base Class Library) 안에 포함되어 있어 손쉽게 사용할 수 있다. C#에서는 기본적으로 비동기 통신을 하면 자동으로 IOCP를 이용한다. 이는 C# 뿐만 아니라 닷넷의 기본 기능인 것이다. 또한 플래시는 이번에 MX 버전이 출시되면서 많은 기능의 개선이 있었다. 플래시 5부터 XML 소켓을 지원해 지속적으로 연결된 상태에서 네트워크 통신이 가능해졌으며 온라인 게임으로까지 영역을 넓힐 수 있게 됐다.
앞으로 총 4회의 연재를 통하여 온라인 게임 서버로서의 C#의 가능성을 알아보고, 게임 클라이언트로서 플래시의 가능성에 대해 알아볼 것이다. 기존 온라인 게임의 경우 프로그램을 다운받아 플레이해야 했으나 플래시로 온라인 게임을 만들 경우, 스트리밍 방식을 이용하여 별도의 다운로드없이 실시간으로 데이터를 주고받음으로써 즉시 플레이가 가능하다. 초보자도 해당 홈페이지에 접속하기만 하면 바로 플레이할 수 있기 때문에 누구나 쉽게 게임을 시작할 수 있다.
필자는 이러한 플래시와 C#의 특징에 주목하여 그 가능성을 테스트한다는 의미에서 포트리스와 비슷한 게임인 ‘심플 포트리스(Simple Fortress)’를 만들어 보았다. 별도의 다운로드 없이 URL 주소만 입력하면 플레이할 수 있으며, 웹 브라우저 내에서 실행되므로 게임을 하면서도 다른 작업창을 실행할 수 있다는 이점이 있다. 본격적인 설명에 들어가기 전에, 이 게임은 필자가 닷넷과 플래시에 대한 테스트용으로 만든 것으로 상업적으로 사용할 의도가 없으며, 이 게임의 거의 모든 이미지와 사운드 파일은 포트리스 2 공식 홈페이지에서 다운받아 사용한 것임을 미리 밝혀둔다.
심플 포트리스 미리보기
앞으로 우리가 만들 게임이 어떤 게임인지 한 번 보도록 하자. ‘이달의 디스켓’의 압축을 풀면 Server와 Client 두 개의 폴더가 있을 것이다. 이중 Server 폴더에서 FortressServer.exe를 실행하면 서버가 작동한다(이 서버 프로그램은 닷넷 기반 하에서만 작동하기 때문에 최소한 닷넷 프레임워크는 설치되어 있어야 한다). 그 다음 Client 폴더의 fortress.html 파일을 실행시킨다. <화면 1>과 <화면 2>는 서버와 클라이언트의 작동 화면이다.
 |
|
 |
| <화면 1> FortessServer.exe 실행화면 |
|
<화면 2> Fortess.html 실행화면 |
웹 브라우저 화면에서 원하는 ID를 입력하고 들어간가면 <화면 3>과 같은 대기실 화면이 나온다. 이 곳에서 탱크 종류와 팀을 선택할 수 있다. 이 상태에서 또 한 번 Fortress.html 파일을 실행해서 새로운 ID를 입력하고 들어오면 두 명의 게이머가 대기실에 들어온 상태가 된다.
 |
|
 |
| <화면 3> 대기실 화면 |
|
<화면 4> 게임 시작 화면 |
이때 두 개의 웹 브라우저에서 동시에 배경음악이 나오므로 약간 혼란스러울 수도 있다. 서로 다른 팀을 고른 후, 처음에 들어왔던 사람이 START 버튼을 누르면 게임이 시작된다(<화면 4>). 게임 방법은 <표 1>과 같다.
|
|
|
| 기능 |
키 |
| 탱크의 이동 |
화살표 좌우 키 |
| 탱크의 각도 조정 |
화살표 상하 키 |
| 대포 발사 |
스페이스 바를 눌러서 파워를 조절 후 발사한다. | | |
| |
|
|
먼저 자신의 차례가 되면 자신의 탱크 위에 ‘READY!’라는 글자가 깜빡거린다. 그 상태에서 각도 조정이나 이동을 하면서 조절한 후 스페이스 바를 길게 눌렀다가 떼면 대포가 발사된다(<화면 5>). 서로 번갈아 가면서 대포를 발사하는 방식으로 게임을 쉽게 하기 위하여 폭발의 파편만 닿아도 생명치를 줄게 해 놓았다. 채팅도 지원하므로 대화를 입력해도 된다(<화면 6>). 이제 어떤 게임인지 살펴봤으니 본격적으로 게임 제작에 착수해 보자. 먼저 서버부터 만들어 볼 것이다.
 |
|
 |
| <화면 5> 대포를 발사한 장면 |
|
<화면 6> 대화를 나누는 장면 |
비동기 호출의 기본은 델리게이트
서버 제작에서 중요한 점은 다수의 사용자를 처리해야 하는 데 있다. 한 명이 아니라 여러 명이 동시에 접속하므로 그들의 요구를 동시에 처리해 줘야만 한다. 그런데 일반적으로 프로그래밍하다 보면 한 명을 처리하기 위해 그 대답을 기다리다가 다른 사람의 요구를 못 들어주게 된다.
즉 블럭이 돼 버려서 다수의 사용자를 처리할 수 없게 된다. 이 때의 해결책이 바로 쓰레드이다. 닷넷에서는 이러한 쓰레드를 이용하여 비동기 호출을 지원하는데, 이를 이용하여 많은 사용자들의 요구를 처리할 수 있다. 이는 함수를 호출할 때 동기적으로 그 함수의 호출이 끝날 때까지 기다리는 것이 아니라 함수를 호출하면 그 함수는 새로운 쓰레드 안에서 돌아가고 호출자 또한 기존 쓰레드 내에서 돌아가므로 동시에 일을 처리할 수 있게 된다.
 |
| <그림 1> 동기 호출과 비동기 호출 |
<그림 1>은 소켓의 Accept문을 예로 들어 동기 호출과 비동기 호출의 차이점을 설명한 그림이다. 이 비동기 호출의 핵심 개념에는 바로 델리게이트(delegate)라는 것이 자리잡고 있다. 그러므로 델리게이트의 본질부터 파악하는 것이 비동기 호출의 원리를 이해하는 방법일 것이다.
C# 세계의 브로커, 델리게이트
C#을 배우는 사람들에게 있어 델리게이트는 생소한 개념이 아닐 수 없다. 델리게이트는 C 언어의 함수 포인터에서부터 유래되었다. C 언어에서는 함수 포인터를 잘 안 썼으므로 생소할 수도 있다. 먼저 델리게이트의 사전적인 의미를 살펴보면 ‘대리자’ 또는 ‘위임형’ 등으로 정의하고 있다. 델리게이트라는 것이 어떤 함수를 대신해서 호출되기 때문에 그렇게 이름을 붙인 듯하다. 이해를 돕기 위해 다음과 같은 기상청 시나리오를 살펴보자.
기상청에서는 기상정보를 수집해 그 정보를 필요로 하는 곳에 전달한다. 그런데 누가 언제 그러한 정보를 필요로 할지 미리 알수 없기 때문에 그런 보고 시스템을 미리 구축해 놓을 수 없었다. 그래서 대신 기상 정보 브로커를 고용해 그에게 정보를 주면, 그가 자신에게 연결된 기상 정보를 필요로 하는 사람들에게 그 정보를 주기로 했다. 그렇게 해서 보고 시스템을 완성하게 됐다. 이에 신문사가 제일 처음 그 정보를 달라고 브로커에게 요청을 했다. 브로커는 그 요청을 받아들이고 기상청으로부터 기상 정보를 받는대로 신문사에게 전해 주기로 했다.
 |
| <그림 2> 기상 브로커 시나리오 |
이를 그림으로 나타내면 <그림 2>와 같다. 그러면 이를 코딩으로 나타내 보자. 미래의 일은 예측할 수 없기 때문에 이미 모든 계획은 다 세웠지만 누가 그 계획에 참여할지는 모를 때가 있다. 프로그래밍의 세계에서도 누가 그 일에 참여하게 될지 모르는 상황이 종종 생긴다. 이럴 때 델리게이트를 사용하는 것이다. 차후에 델리게이트를 통해서 그 일을 할 메쏘드만 연결시켜주면 된다.
|
|
namespace MeteorologicalSystem
{
// 기상 정보 브로커
public delegate void Information(int temparature, int humidity,
string nephanalysis);
// 기상청
class MeteorologicalOffice
{
// 기상 예보
public static void Report(Information broker)
{
broker(25,60,”구름 없음”);
}
}
// 신문사
class NewspaperCompany
{
// 신문사에서 신문을 발간
public static void Publish(int temparature, int humidity,
string nephanalysis)
{
Console.WriteLine(“[신문사 출판] 온도:{0}, 습도:{1}, 구름분포:{2}”,
temparature, humidity, nephanalysis);
}
}
// <summary>
// Class1에 대한 요약 설명
// </summary>
class Class1
{
// 해당 응용 프로그램의 주 진입점
[STAThread]
static void Main(string[] args)
{
// TODO: 여기에 응용 프로그램을 시작하는 코드를 추가
// 첫번째 예제
Console.WriteLine(“=== 첫번째 예제 ===”);
Information broker = new Information
(NewspaperCompany.Publish);
// 신문사 등록
MeteorologicalOffice.Report(broker); // 기상정보 보고 시스템 가동
}
}
}
| |
|
델리게이트의 비밀을 파헤치자
<리스트 1>을 보면 한 가지 궁금증이 떠오를 수도 있다. 마지막 줄을 다시 보자.
Information broker =
new Information(NewspaperCompany.Publish);
여기서 왜 new라는 키워드를 썼는지 궁금증이 일어날 것이다. new라는 것은 새로운 Object를 할당할 때에만 쓰는 키워드인데, 여기서 사용했다는 것은 마치 클래스를 할당하는 것과 비슷하다고 생각할 수 있다. 만약 그렇게 생각했다면 맞다. 델리게이트라는 것이 바로 클래스이기 때문이다. 델리게이트를 ‘위임[형]’이라고 번역하듯이 델리게이트는 클래스 타입이다. 그러면 클래스 바디는 어디에 있는 걸까? 클래스라면 다음과 같이 되어 있어야 한다.
Class Information
{
}
하지만 클래스의 정의가 다음과 같이 한 줄로 되어 있다.
delegate void Information(int temparature, int humidity, string nephanalysis);
도대체 바디는 어디에 있는가? 사실 이 한 줄에는 바디를 포함하고 있다(<그림 3>). 즉 리턴형과 인자형에 대한 정보가 클래스 바디가 되는 것이다.
 |
| <그림 3> DeleBang의 클래스 바디 |
델리게이트가 정말 클래스인지 확인해 보기 위하여 중간 코드로 확인해 보자. 닷넷을 설치한 폴더에 ILDA SM.exe 파일이 있다. 이는 IL Disassembler의 약자로 말 그대로 중간 코드를 disassemble해 준다. 이를 통해 앞에서 컴파일한 Meteorological System.exe 파일을 열어 보면 <화면 7>이 나타난다. <화면 7>을 보면 글자 옆에 아이콘들이 있는데, 이들이 무엇을 의미하는지는 <화면 8>을 보면 알 수 있다.
 |
| <화면 7> MeteorologicalSystem.exe를 Disassemble한 화면 |
 |
| <화면 8> 아이콘 도움말 |
이를 통해서 보면 Information은 클래스라는 것과 .ctor, BeginInvoke, EndInvoke, Invoke라는 네 개의 메쏘드를 가지고 있음을 알 수 있다. 또한 Information은 System.Muticastdele gate에서 상속받았다는 정보까지 갖고 있다. 여기에 나오는 4개의 메쏘드중 .ctor은 생성자를 의미한다. BeginInvoke와 EndInvoke는 비동기 호출에 쓰이며, Invoke는 동기 호출에 쓰이는 메쏘드이다. 이들에 대한 코드는 <리스트 2>와 같다.
|
<리스트 2> Information 클래스의 코드 | |
| |
public class Information : System.Multicastdelegate
{
// 생성자
public Information (object target, int32 methodPtr);
public void virtual Invoke( int temparature, int humidity,
string nephanalysis );
public virtual IAsyncResult BeginInvoke( int temparature,
int humidity, string nephanalysis,
AsyncCallback callback, Object object);
public virtual void EndInvoke( IAsyncResult result);
}
| |
|
|
|
|
| 필드 |
타입 |
설 명 |
| _target |
System.Object |
인스턴스 메쏘드에 쓰이는 것으로, 콜백메쏘드가 호출될때 참조하는 Object이다. |
| _methodPtr |
System.Int32 |
CLR에서 사용되는데, 콜백될 메쏘드를 가리키는 integer 값 |
| _prev |
System.Multicastdelegate |
다른 델리게이트를 가리키는 값 | | |
| |
|
|
<리스트 2>를 보면 한 가지 이상한 점을 발견할 수 있을 것이다. 바로 Information의 생성자인데, 우리는 <리스트 1>에서 생성자로 NespaperCompany.Publish를 넘겨줬다. 그런데 <리스트 2>를 보면 생성자는 두 개의 인자가 필요하다. 분명 에러를 발생해야 하는데 잘 되는 것을 보면 이상이 없는 것이다. 여기서 컴파일러는 원본 소스를 컴파일할 때, 앞의 생성자에 맞도록 파싱을 해주기 때문에 에러가 안 나는 것이다.
앞의 두 인자중 target은 메쏘드가 있는 오브젝트를 가리키는데 만약 메쏘드가 static이면 null 값을 넘겨준다. methodPtr은 callback 메쏘드를 가리키는 CLR 내부에서 쓰이는 레퍼런스 값이다. 이들 생성자에서 받은 두 개의 값을 Information 클래스는 따로 Private 필드에 저장해 두는데 그 Private 필드는 <표 2>와 같다.
이중 _prev 값은 나중에 Muticatedelegate에서 설명할 것이다. 그럼 이제 우리가 생성자에게 넘겨준 그 값들을 직접 눈으로 확인해 보자. <리스트 1>에서 main 메쏘드에 다음과 같은 코드를 추가하자.
// 생성자에 넘겨준 값을 보자.
if ( broker.Target == null )
{
Console.WriteLine(“null”);
}
else
{
Console.WriteLine(broker.Target);
}
Console.WriteLine(broker.Method);
이를 실행하면 다음과 같은 결과를 볼 수 있다.
=== 첫번째 예제 ===
[신문사 출판] 온도 : 25, 습도 : 60, 구름분포 : 구름 없음
=== 두번째 예제 ===
null
Void Publish(Int32, Int32, System.String)
우리가 넘겨준 메쏘드가 Static이기 때문에 Target에는 null 값이 들어갔고, 메쏘드에는 대리자에 등록된 메쏘드의 형식이 나왔다. 만약 여기에서 instance 메쏘드를 넘겨주면 어떤 값이 나올까? 앞에서 Kill 메쏘드에서 static을 빼고, NewspaperCompany 클래스를 새로 생성해서 실행해 보면 다음과 같은 결과가 나온다. 즉 메쏘드의 Object를 넘겨주는 것이다.
=== 첫번째 예제 ===
[신문사 출판] 온도 : 25, 습도 : 60, 구름분포 : 구름 없음
=== 두번째 예제 ===
MeteorologicalSystem.NewspaperCompany
Void Publish(Int32, Int32, System.String)
이제 생성자에 대한 비밀은 풀었으나 아직 Information 클래스의 메쏘드에 대한 비밀이 남아 있다. <리스트 2>에서 Invoke 메쏘드가 있는데 이것이 실제 실행하는 메쏘드이다. 그런데 우리는 그 메쏘드를 호출한 적이 없다. 그러면 컴파일러가 알아서 호출해 주는 것일까? 그렇게 생각했다면 정답이다. 우리는 <리스트 1>에서 다음과 같이 호출했다.
broker(25,60,”구름 없음”);
컴파일러는 이 코드를 보고 다음과 같이 번역한다.
broker.Invoke(25,60,”구름 없음”);
그런데 정말 이렇게 번역하는 것일까? 이것 역시 ILDASM을 이용해서 확인해 보자. <화면 9>를 보면 컴파일러가 만들어 준 Invoke 메쏘드를 볼 수 있을 것이다.
 |
|
|
| <화면 9> Invoke가 호출된 부분 |
|
<화면 10> += 연산자가 나타내는 메쏘드 |
너에게 임무를 추가한다!
이제 델리게이트에 대해 어느 정도 비밀을 풀었다. 그런데 여기서 한 가지 의문이 남아 있다. <표 2>를 보면 _prev라는 필드가 있는데 이 필드의 용도가 무엇이냐 하는 것이다. 이를 위해 다음과 같은 시나리오를 보자.
어느 날 방송사에서도 그 기상 정보를 달라는 요청이 들어왔다. 이미 기상청에서는 브로커에게 그 일을 일임했으므로 방송사는 브로커와 거래를 해 등록함으로써 브로커를 통해 기상청의 정보를 제공받게 된다. 이를 코드로 나타내면 다음과 같다. 먼저 Broadcasting Company 클래스를 다음과 같이 새로 만든다.
// 방송사
class BroadcastingCompany
{
// 방송사에서 방송 보도
public static void Broadcast( int temparature,
int humidity, string nephanalysis)
{
Console.WriteLine(“[방송 보도] 온도:{0}, 습도:{1}, 구름분포:{2}”,
temparature, humidity, nephanalysis);
}
}
그 다음 브로커에 다음과 같이 추가하면 된다.
broker += new Information(BroadcastingCompany.Broadcast);
결과는 다음과 같다.
=== 세번째 예제 ===
[신문사 출판] 온도 : 25, 습도 : 60, 구름분포 : 구름 없음
[방송 보도] 온도 : 25, 습도 : 60, 구름분포 : 구름 없음
여기서는 단순히 += 연산자를 이용했다. C#에서는 연산자 오버로딩을 지원하기 때문에 += 연산자는 실질적으로 메쏘드를 호출하는 것이다. 그러면 그 메쏘드가 무엇인지 ILDASM을 통해 확인해 보자. <화면 10>을 보면 Combine이라는 메쏘드가 호출됨을 볼 수 있다.
기본적으로 델리게이트 타입은 Muticastdelegate를 상속받으므로 하나의 callback 메쏘드가 아닌 다수의 callback 메쏘드를 가질 수 있다. 앞의 시나리오에서 보듯이 어떤 사건에 의해 다수가 그 영향을 받는 경우가 있기 때문에 이러한 기능을 지원하는 것이다. 델리게이트 내부적으로는 이것을 linked-list로 유지를 한다. linked-list로 유지하기 때문에 앞의 링크를 가리키는 _prev 필드가 필요한 것이다. 이를 그림으로 나타내면 <그림 4>와 같다.
 |
| <그림 4> 브로커의 linked-list |
이 그림을 보면 한 가지 의문점이 들 것이다. 우선 브로커가 처음에 등록했던 신문사를 가리키는 것이 아니고 나중에 등록한 방송사를 가리킨다는 것과 일반적인 linked-list에서는 _next 필드로 다음 오브젝트를 가리키는 데 비해 여기는 _prev필드를 써서 앞의 오브젝트를 가리킨다는 것이다. 그 이유는 리턴 값 때문에 그렇다. 만약 callback 메쏘드에 리턴 값이 있다면 어떻게 할 것인가? 예를 들어 다음과 같은 경우이다.
delegate int Information(int temparature, int humidity,
string nephanalysis);
이와 같이 리턴 값이 있는 경우 브로커에 등록된 callback 메쏘드가 한 개라면 별 문제가 없지만, 여러 개라면 어떻게 할까? 먼저 C#에서는 여러 개의 callback 메쏘드중 단 한개의 리턴 값만 받아 올 수 있다. 그 여러 개의 리턴 값을 다 받아오려면 다른 방법을 취해야 하는데 그 방법은 나중에 소개할 것이다. 일단 일반적인 상황에서는 리턴 값을 하나만 취한다.
그러면 어떤 리턴 값을 취할 것인가? 상식적으로 생각해 보면 가장 최근에 호출된 callback 메쏘드의 리턴 값이 가장 가치있다고 생각될 것이다. 그래서 가장 나중에 호출된 리턴 값이 필요하기 때문에 _next 필드를 안 쓰고 위로 거슬러 올라가서 호출하는 것이다. _next를 쓴 경우와 _prev를 쓴 경우를 그림으로 비교해 보자. 예를 들어 f1, f2, f3를 브로커에 등록했다고 하면 <그림 5>와 같은 호출 과정을 볼 수 있다.
 |
| <그림 5> _prev와 _next의 차이점 |
그러면 직접 호출을 담당하는 Invoke 메쏘드에 대한 가상 코드를 만들어 보자.
class Information : Multicastdelegate
{
public int virtual Invoke(int temparature, int humidity,
string nephanalysis)
{
// 앞으로 거슬러 올라간다.
if ( _prev != null ) _prev.Invoke(temparature,
humidity,
nephanalysis);
// 결국 맨 나중에 호출된 callback 메쏘드의 리턴 값이 리턴된다.
return _target.methodPtr ( temparature, humidity,
nephanalysis);
}
}
그럼 이제 _prev를 살펴봤으니, Combine 메쏘드가 내부적으로 어떻게 이들 연결을 만드는지 보자. <리스트 3>은 델리게이트 클래스의 Combine 메쏘드들이다. Combine 메쏘드는 두 개의 델리게이트를 인자로 받는데, 먼저 delegate는 한 번 생성되면 immutable하기 때문에 _prev 필드를 마음대로 변경할 수가 없다. 그래서 Combine을 할 때에는 second와 같은 새로운 델리게이트 오브젝트를 생성하고, 이때 _prev 필드 값을 first로 설정해 준다.
|
|
class System.delegate
{
// first와 second를 연결한 후에 second를 리턴한다.
public static delegate Combine(delegate first, delegate second);
// 배열에 의한 델리게이트를 연결시켜 준다.
public static delegate Combine(delegate[] delegateArray);
// 델리게이트를 chain에서 제거
public static Remove(delegate source, delegate value);
}
| |
|
그렇다면 이를 이용해서 Combine 메쏘드가 정말 새로운 오브젝트를 생성해서 리턴하는지 다음과 같은 코드를 보자. 다음 결과를 보면 False가 나온다. Combine 메쏘드가 새로운 델리게이트를 새로 생성해서 리턴하기 때문이다.
Information broker1 =
new Information(NewspaperCompany.Publish);
Information broker2 = (Information) delegate.Combine(broker1,
broker1);
Console.WriteLine( (object) broker1 == (object) broker2 );
델리게이트에 Combine시키는 방법이 있으니 Remove시키는 방법도 있을 것이다. 다음과 같은 경우를 보자.
broker -= new Information(NewspaperCompany.Publish);
MeteorologicalOffice.Report(broker);
앞에서 브로커에게 신문사와 방송사를 다 등록시켰는데 이번에는 신문사를 제거해 봤다. 이 -= 연산자 또한 실제로는 Remove 메쏘드를 나타낸다. 이는 <리스트 3>에서 보듯이 두 개의 인자를 취하는데, 첫 번째는 linked-list를 이루고 있는 델리게이트의 헤드를 가리키며, 두 번째는 삭제할 델리게이트를 가리킨다. 그런데 왜 지우는데 오브젝트를 새로 생성할까? linked-list에서 원하는 것을 찾아서 지워야 하는데, 이를 비교하는 방법에 그 원인이 있다.
우리가 정확히 찾고자 하는 것은 NewspaperCompany. Publish로 이를 비교해야만 하는 것이다. 그런데 앞서서 델리게이트 클래스에서 생성자로 넘겨주는 것으로 _target과 _method Ptr이 있었다. 즉 instance/static이냐 하는 것과, 리턴 값과 인자형에 따라 클래스를 구분할 수 있는 것이다. 그렇기 때문에 델리게이트에서는 동등 비교를 하는 데 있어 _target과 _methodPtr을 이용한다. 다을 실행하면 TRUE를 리턴하는 것을 볼 수 있다.
Information broker3 =
new Information(NewspaperCompany.Publish);
Information broker4 =
new Information(NewspaperCompany.Publish);
Console.WriteLine(broker3.Equals(broker4));
이제 델리게이트에 다른 델리게이트를 쉽게 추가/삭제할 수 있게 됐다. 그러나 앞서 얘기했듯이 델리게이트의 linked-list 호출 구조는 한 가지 단점을 지니고 있다. 중간의 리턴 값들을 무시한다는 것이다. 게다가 만에 하나 리스트들 중에서 exception이 일어나든가 블러킹(blocking)되기라도 하면, 뒤에 딸려 있는 리스트들은 모두 호출되지 못하고 멈춰버린다.
이럴 때에는 알아서 호출하게 놔두지 말고 사용자가 직접 하나하나 체크해 가면서 호출하면 된다. C#에서는 이와 같은 문제를 해결하기 위해 GetInvoca tionList()라는 함수를 제공하고 있다. 이를 이용하면 linked-list의 각 구성원을 똑같이 복사한 배열로 리턴받을 수 있다. 단 이때 _prev 필드는 필요없기 때문에 null로 셋팅이 된다.
delegate[] arraydelegates = broker.GetInvocationList();
foreach(Information agent in arraydelegates)
{
Console.WriteLine(agent.Method);
}
이벤트 핸들러로 임명합니다~
이제 마지막으로 이벤트에 대해 알아 보자. 이벤트는 한 오브젝트에서 어떤 일이 일어나서 그 일을 다른 오브젝트에게 알려줄 때 이용한다. 이는 델리게이트와도 많이 유사한데, 실제로도 델리게이트를 이용하므로 이벤트는 델리게이트의 특별한 용도라고 생각하면 된다. 예를 들어 앞서 정의한 기상정보 시스템을 이벤트로 만들어 보자. 이때 이벤트라는 의미에 좀더 충실하기 위해 기상 특보를 기상청에서 발령한다고 가상해 보았다. 이때 기상청에서는 자신의 이벤트에 등록된 신문사에게 통지해 준다. <리스트 4>를 보자.
|
|
namespace MeteorologicalSystem2
{
// 기상청
class MeteorologicalOffice
{
// 이벤트 인자 정의
public class SpecialReportEventArgs : EventArgs
{
public SpecialReportEventArgs(string nephanalysis)
{
this.nephanalysis = nephanalysis;
}
// 이벤트 인자 내에서 쓸 목록
public readonly string nephanalysis;
}
// 위임형 선언
public delegate void SpecialReportEventHandler( object sender ,
SpecialReportEventArgs args);
// 이벤트 정의
public event SpecialReportEventHandler SpecialReport;
// 이벤트를 발생시키는 함수
protected virtual void OnSpecialReport(SpecialReportEventArgs e)
{
if ( SpecialReport != null )
{
SpecialReport(this,e);
}
}
// 이벤트 발생을 위해 테스트용으로 만든 함수
public void SimulateEvent(string nephanalysis)
{
SpecialReportEventArgs e = new SpecialReportEventArgs
(nephanalysis);
OnSpecialReport(e);
}
}
// 신문사
class NewspaperCompany
{
public NewspaperCompany( MeteorologicalOffice mm)
{
mm.SpecialReport += new MeteorologicalOffice.
SpecialReportEventHandler(Publish);
}
// 신문사에서 신문을 발간
public static void Publish( object sender , MeteorologicalOffice.
SpecialReportEventArgs e)
{
Console.WriteLine(“[신문사 특보] 구름분포:{0}”, e.nephanalysis);
}
}
// Class2에 대한 요약 설명
class Class2
{
// 해당 응용 프로그램의 주 진입점
[STAThread]
static void Main(string[] args)
{
// TODO: 여기에 응용 프로그램을 시작하는 코드를 추가
MeteorologicalOffice office = new MeteorologicalOffice();
NewspaperCompany company = new NewspaperCompany(office);
office.SimulateEvent(“태풍 북상”); // 이벤트를 넣어줌
}
}
}
| |
|
이벤트 이용에는 몇 가지 관례가 있다. 먼저 일반적인 델리게이트에서는 인자에 제한이 없지만 이벤트에서는 두 개의 인자를 사용한다. 그 두 개는 보내는 이가 누구인지 나타내는 object형과 System.EventArgs에서 상속받은 클래스를 인자로 받는 것이 있다. 먼저 받는 사람이 여러 사람의 이벤트에 등록해 두면 누가 보냈는지 알 수 없으므로 누가 보냈는지 알기 위해 첫 번째 인자로 object형 인자를 받는다.
예를 들면 신문사는 정보를 기상청으로부터 들을 수도 있지만 소식이 들어오는 경로는 여러 군데일 것이다. 누가 그 정보를 보냈는지 알아야 할 때가 있기 때문에 이런 방법을 사용하는 것이다. 두 번째 인자는 EventArgs를 상속받은 클래스인데 이를 사용면 좀더 깔끔하게 인자 관리를 할 수 있다(그러나 여기서는 편의를 위해서 단순하게 하나의 인자만 썼다).
이벤트에서는 이름을 정하는 데 있어서도 몇 가지 관례가 있다. 먼저 System.EventArgs를 상속받는 클래스는 그 이름 끝에 EventArgs를 붙여준다. 또한 델리게이트를 선언시에도 이름 뒤에 EventHandler를 붙여준다. 마지막으로 이벤트를 발생시키는 메쏘드는 이름 앞에 On을 붙여준다. <리스트 4>를 보면 그냥 이벤트 키워드없이 관례만 따라주면 이벤트가 되지 않느냐고 물을 수 있는데 사실 이벤트는 내부적으로 또 다른 일을 하고 있다. 무슨 일을 내부적으로 꾸미는지 알기 위해 ILDASM으로 확인해 보자.
 |
| <화면 11> 이벤트가 들어간 클래스 |
<화면 11>을 보면 생성하지 않았던 두 개의 함수가 추가되어 있는 것을 볼 수 있다. 게다가 우리는 SpecialReport를 public으로 선언을 했는데 private으로 되어 있다. 이를 가상 코드로 나타내 보자.
private SpecialReportEventHandler SpecialReport = null;
// 이벤트 등록 메쏘드
[MethodImpAttribute(MethodImplOption.Synchronized)]
public void add_SpecialReport(SpecialReportEventHandler handler)
{
SpecialReport = (SpecialReportEventHandler)
delegate.Combine
(SpecialReport, handler);
}
// 이벤트 등록해제 메쏘드
[MethodImpAttribute(MethodImplOption.Synchronized)]
public void remove_SpecialReport(SpecialReportEventHandler handler)
{
SpecialReport = (SpecialReportEventHandler)
delegate.Remove
(SpecialReport, handler);
}
먼저 우리가 public으로 선언한 SpecialReport가 private으로 되어 있으면서 null로 초기화되어 있다. 이는 이벤트라는 것을 외부에서 함부로 접근하지 못하게 막기 위함이다. 예를 들어 태풍이 오는 그런 급박한 상황에서만 이벤트가 발생해야 하는데 이를 public으로 둘 경우 외부에서 마음대로 통제하거나, 바람이 불어도 기상 특보를 발령하는 우를 범할 수가 있기 때문이다. 그래서 이벤트는 그 이벤트를 소유한 클래스 내에서만 발생시킬 수 있게 하기 위해 private 필드로 두는 것이다.
또한 add_＊와 remove_*라는 두개의 메쏘드가 추가됐는데, 이는 메쏘드명에서 알 수 있듯이 이벤트에 등록자(listener)들을 등록/해제하는 역할을 한다. +=와 -=연산자를 쓰면 add_*나 remove_*로 컴파일러가 바꿔 준다. Combine이나 Remove를 쓴 경우와 다르지 않게 보일 수 있으나, 자세히 보면 메쏘드 위에 애트리뷰트가 있다.
이는 메쏘드를 동기화시켜서 쓰레드에 대한 안정성을 보장해 준다. 예를 들면 두 개의 리스너가 동시에 이벤트에 등록/해제해도 linked-list가 깨지지 않고 올바로 유지된다(<화면 12>). 결론적으로 이벤트는 결국 델리게이트의 특별한 케이스인데 보다 보안과 안정성에 중점을 둔 케이스라고 할 수 있다.
 |
| <화면 12> 동기화된 메쏘드 |
다음 글에서는 비동기 프로그래밍을
이번 글에서는 서버 구축하는 데 있어 필수인 비동기 소켓 프로그�
Copyright ⓒ hompy.info. All rights reserved.
