씩씩하게 가기

.NET Remoting에서 remote object의 lifetime은 type에 따라서 잘 설명되는 것을 볼 수 있다.

http://msdn.microsoft.com/en-us/library/ms973864.aspx의 비교표

그런데 remote object이 HTTP/HTTPS channel을 사용할때 이 HTTP connection은 remote object과 어떤 구조로 연결되며 lifetime은 어떨까?

이의 의문을 해결하기 위해 검색하다보니 다음 문서를 찾게 되었다.

Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption Channel Sink

http://msdn.microsoft.com/en-us/magazine/cc300447.aspx

Support for HTTPS

In conversations about remoting, the word "channel" is used frequently. Its definition can vary, but in general, a channel is the series of sinks through which a remoting call is made. The HTTP channel for .NET is actually a combination of two channels, one used by the client and one used by the server. Each has its own set of sinks, referred to as a "sink chain." The client sink chain ends with the HttpClientTransportSink, which uses the HttpWebRequest and HttpWebReponse classes from the System.Net namespace to handle all HTTP traffic. This brings with it a bonus—since HttpWebRequest and HttpWebResponse support HTTPS, so too does the HTTP client channel. This means that if the server channel supported SSL, you'd be all set. 

이 문장의 의미를 해석하기 위해 다음의 architecture 구조가 도움이 된다. 즉, client쪽과 server쪽은 각각 sink chain 구조를 가지는데, client chain 중 마지막 단계인 Transport Sink에서 .NET의 HttpWebRequest class와 HttpWebResponse class를 사용하게 되고 이들의 instance가 바로 HTTP traffic을 담당한다는 얘기다. HttpWebRequest class와 HttpWebResponse classs는 HTTPS도 지원하므로 서버쪽에서 SSL을 지원한다면 그것으로 SSL이 이뤄진다는 말이다.

.NET Remoting Architecture (http://man.ddvip.com/web/bsaspnetapp/LiB0096.html)

Figure 11.1 on the next page shows the basic .NET Remoting architecture when a remote object is hosted within ASP.NET. An ASP.NET host, coupled with the HTTP channel for communication, is the recommended approach if security is the key concern, because it allows the remote object to utilize the underlying security services provided by ASP.NET and IIS.

Figure 11.1: The .NET remoting architecture

그런데 이 HTTP connection은 언제 끝나게 될까? 이는 실제 .NET Remoting 구현에서 디버깅을 해보면 가장 정확하겠지만 다음 언급으로 대략 짐작이 간다.

Architecting And Building Enterprise Solutions With Com+ & .Net 책 인용,

 Whenver the client destroys the reference to remote object, the HTTP connection is closed 

http://www.dotnet247.com/247reference/msgs/5/27261.aspx

In fact, the overhead occurs mostly on the _first_ method call to the remote host. During this first call the HTTPS connection will be established and keys will be "negotiated". After this, the calls should be quite fast and "small". 

>> remote host로 첫 method cal 일 경우에만 HTTPS connection이 establishe되면서 overhaed가 있고 이후 call에는 빠르다는 것은 connection이 remote object에 대한 client reference가 내려갈 때가지 유지한다는 얘기..

실제 구현에서 다른 경우가 혹 나오면 다시 note할 예정.

.NET namespace에서 제공되는 transaction은 System.Transactions namespace 와 System.EnterpriseServices namespace(이는 COM+을 사용합니다)이고 (물론 ADO.NET도 가능합니다),

이 방법들이 어떻게 다른지, 특정, 성능 등에 대하여 찾아봤습니다.

각각의 특징에 대해서 가장 잘 정리된 문서는 물론 MSDN입니다.

Transaction Fundamentals

http://msdn.microsoft.com/en-us/library/z80z94hz(VS.90).aspx tree 이하 문서에 System.Transactions 특징들이 잘 설명됩니다.

local transaction 일 경우의 performance gain이 언급되고, distributed transaction일 경우의 DTC로 escalation되는 점, enterprise services and COM+ transaction과의 interoperability 가능 등의 특성을 얘기합니다.

System.EnterpriseServices Namespace

http://msdn.microsoft.com/en-us/library/system.enterpriseservices.aspx

Classes configured in this way can be hosted in a COM+ application and can use COM+ services by way of the EnterpriseServices namespace. For a list of supported services, see Summary of Available COM+ Services.

This namespace provides .NET objects with access to COM+ services making the .NET Framework objects more practical for enterprise applications.

이쪽은 예상하듯이 COM+ 서비스를 이용하는 것이 장점이 될 것이고, 이도 내부적으로는 System.Transactions를 사용한다고 합니다.

궁금한 것은 성능 부분인데 다음 링크들이 성능에 대한 것을 찾아본 결과입니다.

System.Transactions : What to choose?

http://bloggingabout.net/blogs/dennis/archive/2006/09/27/System.Transactions-_3A00_-What-to-choose_3F00_.aspx

System Transactions의 benefit과 함께 성능상 여러 얘기가 언급됩니다.

또한, 참고:

So what are your other options if you don't want or can't use System.Transactions?

1. Enterprise Services
   For many not really an option. On class level you have to configure if you want to join the running transaction and your class has to inherit from the SerivcedComponent class.

2. T-SQL Transactions
   Of course you can always start transactions in your Stored Procedure with BEGIN TRANSACTION. Not very flexible though and in your code you have no idea what's happening in your database. Other dbms have of course their own ways of achieving this. Delivers best performance.

3. ADO.NET Transactions
   Within ADO.NET you can create connections with your SqlConnection object with the BeginTransaction method. Normally however you'd be using multiple classes and methods to execute commands on your database. Enlisting all these commands in the created transaction, you'll have to pass either the connection or Transaction object to every method. This doesn't deserve a price for best design.
   In the background, this is exactly the same as option 2, the T-SQL Transaction. The difference is that you can use the transaction over multiple Stored Procedures (or inline queries). Performance is great, as in option 2.

4. Your own implementation
   Of course you can always implement something yourself, but this is much more complex and might not always be a good solution.
   

Performance versus ADO.Net:

http://blogs.msdn.com/b/natemoch/archive/2005/07/22/442064.aspx

COM+ vs. System.Transactions perfromance

http://social.msdn.microsoft.com/Forums/en/windowstransactionsprogramming/thread/9cdace47-a08e-424d-a811-d70d89d64fe8

• I don’t know how you compare the two, but as long as you are running everything in a distributed transaction, the performance of TransactionScope and ServiceDomain will be almost the same. In both cases most of the work is done by MSDTC and RMs.

TransactionScope will outperform ServiceDomain when you use one connection to a PSPE aware resource manager such as SqlServer 2005.

distributed일 때에는 성능 비교는 거의 같으며(대부분의 일은 MSDTC, RM이 하므로), one connection일 때에는 system.transactions가 낫다는 얘기입니다.

Transactions using EnterpriseServices or System.Transactions - which to use?

http://social.msdn.microsoft.com/Forums/en/windowstransactionsprogramming/thread/4cbdb3fd-b7ea-4c1f-91a0-2e56b22b591e

• If you are already using System.EnterpriseServices today, and you are happy as it is, you don’t have to switch. In-proc ServiceComponents use System.Transactions under the covers and do take benefit of LTM.

• If you are building a new app and you don't need the features (besides transactions) that are offered by ServiceComponents, then use System.Transactions. They are more lightweight and don't force you derive from a base class, don't have requirements for deployment etc. If you do need some of features available in ServiceComponents, I recommend looking at System.ServiceModel (or Windows Communication Foundations). WCF is the unifications of most previous technologies and provides many points of extensibility and customization. For transactions it provides attribute based programming as well as interoperability through WS-AT.

물론 세부사항이 조금 다른 식의 링크들도 있긴 한데 검증이 잘 안되서 일단 생략..

그래도 혹 놓친 관점이 있을 수도 있겠네요.

IE에서 smart client를 object tag의 classid로 명시하여 사용한다는 것은 예를 들어 다음과 같은 코드 형태를 말한다 (http://support.microsoft.com/kb/911721/en-us

의 예제를 빌려왔으니 code behind까지 만드는 전체 예제는 이 링크를 참조할 것)

<%@ Page Language="C#" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

    <title>Untitled Page</title>

    <s-ript language=javas-ript>

        function TestData()

        {

            alert('Test1');

            form1.TestControl.TestProperty = "gomusin";

            alert(form1.TestControl.TestProperty);

        }

        function TestData1()

        {

            alert('Test2');

            var sData = form1.TestControl.TestProperty;

            alert(sData);

        }

    </script>

</head>

<body>

    <form id="form1" runat="server">

    <div>

        <object id="TestControl" classid="SmartClient.dll#SmartClient.UserControl1" VIEWASTEXT>

        </object>

        <input id="Button2" type="button" value="Property Read" style="width: 165px" onclick="javas-ript:TestData1()" />

        <input id="Button1" type="button" value="Property Write" style="width: 168px" onclick="javas-ript:TestData()"/>

</div>

    </form>

</body>

</html>

사용한 예제에서 SmartClient.dll은 strong named assembly이고 UserControl1은 또다른 smartclient2.dll을 참조하고 있다.

그런데 이러한 형태가 잘 사용되다가 smartclient.dll과smartclient2.dll의 version을 올려서 이 코드를 수행해보면form1.TestControl.TestProperty의 값을 인식하지 못하는 현상이 발생한다. 디버깅을 해보면 정확히는 TestControl이 undefined로 인식된다.

반면, 동일 클라이언트에서 dll의 version을 올리지 않은 이전 웹페이지쪽을 수행하면 문제없이 잘 수행된다.

원인을 알기 위해 이런 저런 테스트를 해본 결과, 아무래도 이는 smartclient.dll이 strong named assembly인 것에 기인한다고 보인다.

http://imakeworld.egloos.com/9894243에서도 비슷한 말을 한다.

이유를 알기 위해 fusion log 등과 덤프 분석이 병행되면 좋겠지만 시간 관계상 생략되었다. 이미 밝혀진 근거가 있는지 찾는 것도 일단을 생략하고 위와 같은 구조를 피해나가는 방향으로 선회하였다.

다음 얘기가 관련이 있는지는 미지수이지만 그나마 검색된 것이다.

About Fusion Download Cache

http://blogs.gotdotnet.com/alanshi/CategoryView.aspx/Assembly%20Download

Because simply-named assemblies are not unique (and can be hence updated in-place at any time), they are always re-downloaded from the server. Strongly-named

assemblies may be re-used from the download cache if the URL where Fusion will probe for the assembly matches the URL of the cached bits (and the assemblies have

the same strong identity).   

How to use the AllowPartiallyTrustedCallers attribute to call an assembly that has a strong name from a Web page by using Visual C# .NET

http://support.microsoft.com/default.aspx?scid=kb;en-us;839300

Visual Studio command prompt 창을 하나 열어 caspol.exe로써 설정을 확인하려 할 때 이미 설정되었다고 생각했던 값들이 보이지 않아 당황했는데, 알고보니 이유는 다음과 같은 간단한 것에 있었다.

CAS 설정은 .NET 버전별로, 또한 32bit, 64bit 각각 개별로 적용된다.

또한, 버전별 .NET framework 설치 폴더에 caspol.exe이 각각 존재한다.

Visual Studio command prompt 창에서 실행한 caspol.exe는 environment path 설정에 따라 이 중의 어느 하나가 실행된 것이었고 내가 확인하려던 64bit .NET Framework의 설정값이 보인 것이 아니었다.

유의! 

array와 pointer는 매우 밀접한 관계가 있으므로 기능 차이를 정리해본다.

배열의 특성이란 말할 것도 없이 index로 참조 가능하다. 배열의 각 요소는 storage상에 consecutive한 것을 기억하자.

int a[] = {0, 1, 2, 3, 4};

int i, *p;

//배열의 특성: index로 참조

printf("\n1:\n");

for (i=0; i<=4; i++)

printf("%d", a[i]);

포인터가 배열 요소의 주소를 가리키도록 하며 필요한 array manipulation을 하는 것은 많이 쓰는 모습이다.

//포인터의 특성: 배열 요소의 주소를 가리키면서 manipulation: 증감(+, -, ++, --), dereferencing (*p)

printf("\n2:\n");

for (p=a;p<=a+4; p++)

printf("%d", *p);

또한, 포인터는 하나의 변수이므로 &로써 포인터 변수의 address를 얻을 수도 있다.

//포인터는 변수이므로 변수의 address 얻을 수 있음

printf("\n3:\n");

p = a;

printf("%d", &p)

그런데 배열과 포인터는 이외에도 공통 특성을 많이 공유한다.

//포인터도 배열처럼 indexing 가능

printf("\n4:\n");

for (p=a, i=0; i<=4; i++)

printf("%d", p[i]);

//배열도 포인터 연산처럼 증감(+, -) 가능, dereferencing 가능

printf("\n5:\n");

for (i=0; i<=4; i++)

printf("%d", *(a+i));

배열이 못 가지는 포인터 특성은 다음과 같다.

//배열은 포인터 연산 ++(increment), --(decrement) 불가능

printf("\n6:\n");

for (p=&a[4];a<=p; a++)     //compile error C2105: '++' needs l-value

printf("%d", *a);

이 부분에 대해서는 주의가 필요하다. 함수의 파라미터로 배열 변수가 넘어가면 이때에는포인터 변수와 같이 쓰이므로 ++, -- 연산이 가능하다.

void func1(int a[])

{

for (int i=0; i<=4; i++, a++)

printf("%d", *a);

}

//배열의 address: compile 에러 발생하거나 의미상 좀 그렇다..

printf("\n7:\n");

printf("%d %d\n", a, &a);  //type cast 하면 a와&a는 같은 결과를 보임

for (p=&a; p<=a+4; p++)  //compile error C2440: '=': cannot convert from 'int (*)[5]' to 'int *'  //&a가 아니라 &a[0]을 써야 한다.

printf("%d", *p);       

마지막 부분의 printf에서 &a를 disassembly 코드로 어떻게 계산하는지 살펴보자.

00401b33 8d9550feffff    lea     edx,[ebp-1B0h]

00401b39 52              push    edx

00401b3a 8d8550feffff    lea     eax,[ebp-1B0h]

00401b40 50              push    eax

00401b41 6800684000      push    offset Console1!__xi_z+0x1e8 (00406800)

00401b46 ff1578924000    call    dword ptr [Console1!_imp__printf (00409278)]

Printf를 부르기 전 스택에 push를 두 번 하는데, a나 &a나 같은 것을 넣고 있다.