• 기존의 Error 처리 방법에서의 문제점
  
  • 표준화되어 있지 않다.
  • 자기 설명적인 요소가 없다.
  • 하나의 잘 정의된 Package 형태로의 Capsule화가 되어있지 않다.

• .NET에서의 Error 처리
  
  • SEH(Structured Exception Handling)으로만 Error를 Handling 한다.
  • 자연어 설명
  • 호출 스택에 대한 상세한 스냅샷을 포함 가능
  • Exception의 경우 System.Exception에서 상속받아서 ~Exception으로 끝나는 이름을 붙이는 관행이 있다.
  • 사용자 지정 예외의 경우 System.ApplicationException 에서 파생시키는 것이 가장 좋다.
    
    • System.SystemException의 경우, System.Exception에서 파생되어서 나오는 경우가 일반적이다.
    • : Runtime 시에 예외의 근원을 찾아내기가 힘들다.

In LDAP, Property Collection is consisted of string and ActiveDs DataTypes.

For example, if Property.Value is large integer type, this value can cast by ActiveDs.IADsLargeInteger.

this is sample code :

try
{
    string ldap = String.Format("LDAP://{0}", ldapServer);
    DirectoryEntry entry = new DirectoryEntry(ldap);
    entry.Username = SyncmailConstants.DefaultAdminId;
    entry.Password = SyncmailConstants.DefaultAdminPassword;

    DirectorySearcher seacher = new DirectorySearcher(entry, "OU=mailpushcokr");
    SearchResult searchresult = seacher.FindOne();
    DirectoryEntry ouentry = searchresult.GetDirectoryEntry();

    MembershipUserStatics statics = new MembershipUserStatics();
    foreach (DirectoryEntry entity in ouentry.Children)
    {
        if(entity.Properties.Contains("givenName"))
        {
            if (entity.Properties["givenName"].Value.ToString() == "대리점가입자")
            {
                statics.TotalUkeyUserCount++;
                if (!entity.Properties.Contains("lastLogonTimestamp"))
                {
                    statics.UnusedUkeyUserCount++;
                }
            }
            else
            {
                if (!entity.Properties.Contains("lastLogonTimestamp"))
                {
                    statics.UnuseWebUserCount++;
                }
                else
                {
                    ActiveDs.IADsLargeInteger largeIntADSI = (ActiveDs.IADsLargeInteger) entity.Properties["lastLogonTimestamp"][0];
                    Console.WriteLine(largeIntADSI.HighPart);    
                }
            }
            statics.TotalUserCount++;
        }
    }
    return statics;      
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
    return new MembershipUserStatics();   
}

비동기 I/O 패턴은 고성능을 위한 최상의 선택이다.
여러개의 Multi Thread를 이용해서 최고의 성능을 가진 프로그램을 만드는 것도 역시 가능하다. [이론 상으로는..;]
잘 방어된 서버는 클라이언트가 얼마나 오랫동안 유휴상태인지 검사하여 미리 정의된 한계 이상으로 유휴상태가 계속되는 클라이언트에 대해서 연결을 끊어주어야지 된다.

IAsyncResult 를 인자로 받는 BeginAccept, BeginReceive, BeginSend는 각각 비동기 I/O에 대한 최상의 방법으로 제시된다.
각 Begin** Method에서 호출된 AsyncCallBack 함수는 그 내부에서 각각의 End** Method를 수행시켜, 그 결과를 가지고 오게 된다.

이때에, 주의할 점들은 다음과 같다.

• private static void로 선언이 가능할 경우에 선언하라.
  • 비동기적으로 움직이는 함수의 특징상, 여러개의 instance가 만들어지기 쉽다. 이러한 상황에서 instance의 범람은 memory에 영향을 미칠 수가 있기 때문에, static으로 선언해서 이러한 낭비를 줄일 수 있다.
• try~catch 구문을 잘 사용하라.
• BeginAccept에서는 동기화를 위해서 ManualEvent 또는 Monitor로 socket을 잡아놓는 것이 필요하다.

private void SocketDataProcessThreadStart(object sender, DoWorkEventArgs e)
{
    Exit = false;
    socketMain = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
    socketMain.Bind(new IPEndPoint(IPAddress.Any, PortNumber));
    socketMain.Listen(maxPortAccept);

    while (!Exit)
    {
        try
        {
            manualEvent.Reset();
            socketMain.BeginAccept(new AsyncCallback(AcceptCallBack), socketMain);
            manualEvent.WaitOne();
        }
        catch (SocketException ex)
        {
            System.Diagnostics.Debug.WriteLine(ex.Message);
            Console.WriteLine(ex.Message);
            ErrorEvent(ex, "SocketDataProcessThreadStart 에서 에러 발생");
            return;
        }
    }
}

Access Permissions for Web Applications

Like any applications, Web applications need access to various system resources, such as files or databases. These resources are usually protected by access levels granted to different users and groups.

In a Web application, it might not be the application user who is requesting access directly. Instead, the user communicates to the Web application using a browser, and the Web application then requests the resource. This indirect access can introduce an issue of access permission.

There are several strategies for managing access permissions in a Web application. The sections below provide an overview of each option. Links in the topic will point you to topics that contain more information.

Access through Windows Integrated Security

If your Web application runs in an intranet environment — if all users will be running Windows and are behind the same firewall — the application can access resources using Windows integrated security. In this strategy, all users are authenticated as soon as they log on to Windows. The authentication process generates a token containing information for that user. (The token does not contain the user's credentials, only a code indicating that the user has been authenticated.) The Web application can use the token when requesting a local resource. For example, a logged-in user requests a Web Forms page in Internet Explorer. The request is passed to Internet Information Services (IIS) and then to ASP.NET, which can use the user's authentication token to request access to a file on the server computer.

Windows integrated security is generally the most secure option for Web access permissions. If it is practical in your application, you should configure the application to use this option.

For details, see ASP.NET Authentication.

Anonymous Access Using the ASP.NET User Account

In most applications, users typically access Web applications anonymously — that is, they do not initially provide authentication credentials. In that case, the Web application has to assume (impersonate) some identity that it can use to request resources.

By default, when ASP.NET allows anonymous access, the application runs in the context of a special local (not domain) account. The user context depends on the operating system. In Windows 2000 and Windows XP, applications run under the account called ASPNET. In Windows Server 2003, the user context is called NETWORK SERVICE. These user accounts are created during the .NET Framework installation process with a unique, strong password, and are granted only limited permissions. The ASPNET or NETWORK SERVICE user can access only specific folders that are required to run a Web application, such as the \bin directory in which a Web application stores compiled files.

Note   IIS has a similar mechanism for mapping anonymous users to a specific local or domain user. You can use the IIS facility to remap anonymous access for all files in your application, not just ASP.NET files (Web Forms pages and controls). For details, see Microsoft Internet Information Server Security Overview.

If your Web application requires access to other resources on the Web server computer, you can grant permissions to the ASPNET or NETWORK SERVICE user as needed. For example, if the application needs to write a file to a directory, you will need to explicitly grant write permissions to the ASPNET or NETWORK SERVICE account in that directory.

Alternatively, you can specify a different user identity for ASP.NET to use when requesting resources. You can specify a user name (a local or domain user) in whose name requests are made. For details, see ASP.NET Process Identity. For details, see <processModel> Element. Or you can specify that ASP.NET instead run in a system (administrator) context.

Caution   Running ASP.NET applications in the system context allows them to run with administration permissions on the server. If users can take control of your application, they will then have free access to many critical resources on the server.

There are some resources that you cannot by default access using the default user context, because they require access to resources that need administrative-level privileges. For example, if your application needs to create a new event log category using methods in the System.Diagnostics namespace, it cannot do so if it is running in the context of the ASPNET or NETWORK SERVICE user. In that case, you need to either change the application context or make changes that will make the event log accessible to the ASP.NET user account.

Caution   Setting the process identity to a specific user name in place of the ASPNET or NETWORK SERVICE user identity requires that you provide a user name and a password that are both stored in the machine.config file. Storing any credential information can represent a security threat, because if someone manages to get access to the machine.config or if they gain administrator privileges on the Web server computer, they might be able to read or change this private information. Make the machine.config file read-only for all but administrative users. For details about setting the username and password in the machine.config file, see <processModel> Element.

Access Using Provided Credentials

Your Web application can also request resources by providing credentials at run time. This is not possible to all resources, but can work for resources that accept a username and password, such as databases that accept a connection string.

Security Note   Accessing SQL Server using a connection string (known as "mixed mode") is less secure than using Windows integrated security. If the Web server and SQL server are running on the same computer, you can easily and securely use Windows integrated security.

You can get the credentials from the user directly, using Basic, Digest, or Forms authentication. For example, your application might prompt the user to supply a username and password when the user wants to access a restricted part of your site. For details about authentication, see IIS Authentication and ASP.NET Authentication.

Security Note   Prompting the user for a username and password in your application is a potential security threat. Credential information must be transferred from the browser to your server, and ordinary HTTP transfers are unencrypted. For best security when prompting users to provide credentials in your application, you should use secure sockets layer (SSL), which encrypts information before sending it from the browser to the server. For details, see Using Secure Sockets Layer.

After getting credentials from a user, you can pass them on when requesting the resource. For databases, you can usually plug the username and password into a connection string when opening a connection. For other resources, you can call a Windows API called LogonUser that establishes a user context for the information you provide and uses it to request access to a resource.

Sometimes it is more convenient to store credentials directly with your application. For example, it is possible to create a database connection string that hard-codes a user name and password into it. For details, see Accessing SQL Server with Explicit Credentials.

Security Note   Hard-coding credentials into an application is generally not advised, because the information can be read, even if it has been compiled. Even if you do hard-code any user credential information into an application, you should never use a user name that would give a user anything but the most minimal access privileges to a resource.

If you do choose to store credentials as part of an application, you should make an attempt to protect them. One possibility is to use the Data Protection API (DPAPI). For details, see the technical article Windows Data Protection on MSDN Online (http://msdn.microsoft.com/library/de...asp?frame=true).

Accessing Remote Resources (Delegation)

Sometimes the resource required by your application is on a computer other than the Web server. This is recommended for some resources, such as a database. In that case, the application must make a request to the remote computer on behalf of the user. This process is called delegation.

As with any request for resources, a request to a remote computer must include appropriate credentials. If your application allows anonymous access, IIS and ASP.NET do not have the user's credentials and therefore cannot use them during delegation to access remote resources. In that case, you can:

• Get explicit user credentials by prompting for them. The application can then pass these on to the remote computer as needed. If you are working with a SQL Server, you can add the user credentials to a connection string. For an example, see Accessing SQL Server with Explicit Credentials.
• Change the user context of the Web application from the ASPNET or NETWORK SERVICE user to a specific domain user whose credentials can be passed to the remote computer. For an example, see Accessing SQL Server Using a Mapped Windows Domain User.

Note   If you are running the browser and Web server on the same computer and you are logged on as a domain user, delegation to a remote computer is not a problem, since the IIS computer has your credentials. Although this is a common testing scenario, it is a very rare production scenario. If possible, always test access permissions by running the browser and Web server on separate computers.

MBR, Singleton 형식에서만 객체의 수명 임대가 이루어진다.

   COM에서 "singleton"이라는 용어는 클라이언트에서 개체에 대한 참조를 가지고 있는 한 해당 개체는 메모리에서 삭제되지 않음을 의미했습니다. 그러나 .NET Remoting에서 Singleton 개체는 해당 개체에 대해 지정된 수명 임대의 영향을 받으므로 클라이언트에서 현재 해당 개체에 대한 참조를 보유하고 있는 경우라도 개체가 재생될 수 있습니다.MarshalByRefObject의 InitializeLifetimeService 메서드가 null 참조(Visual Basic에서는 Nothing)를 반환하도록 재정의하면 첫 번째 형식의 Singleton 개체를 만들 수 있습니다. 이렇게 하면 호스트 응용 프로그램 도메인이 실행되는 동안은 개체를 메모리에 유지할 수 있습니다. 자세한 내용은 수명 임대를 참조하십시오. 원격 구성 파일에서 초기 임대 기간을 구성하면 두 번째 형식의 Singleton 개체를 만들 수 있습니다.

MBR, SingelCall 형식에서는 데이터의 수명에 대한 논의가 이루어지지 않는다.

: 객체가 new 또는 Activator에 의해서 생성이 될때, Deep-Copy가 이루어지고, 클라이언트에서는 Copy본을 사용하게 된다.

: 서버는 객체에 대한 참조를 모두 잃어버린다.

 MBV(Marshla-By-Value) 개체 즉, 값으로 마샬링되는 개체는 ISerializable을 구현하여 해당 개체의 serialization을 구현하거나 해당 개체를 자동으로 serialize하도록 시스템에 알리는 SerializableAttribute로 데코레이트되어 개체의 serialization 규칙을 선언하지만 MarshalByRefObject를 확장하지는 않습니다. 

원격 시스템에서는 이러한 개체의 전체 복사본을 만들고 이 복사본을 호출하는 응용 프로그램 도메인에 전달합니다. 호출자의 응용 프로그램 도메인에 복사본이 있으면 해당 복사본에 대한 호출은 이 복사본에 대해 직접 수행됩니다. 

또한 인수로 전달되는 MBV 개체도 값으로 전달됩니다.

클래스 인스턴스를 응용 프로그램 또는 컨텍스트 경계를 넘어 값으로 전달하려는 경우, SerializableAttribute 특성을 선언하거나 ISerializable을 구현하는 것 외에는 어떤 작업도 수행할 필요가 없습니다. 

반면 게시된 개체의 크기가 매우 큰 경우 사용량이 많은 네트워크에서 전체 복사본을 전달하는 것은 응용 프로그램에 최선의 선택이 아닐 수도 있습니다. 또한 복사된 개체의 상태에 대한 변경 내용은 원래 응용 프로그램 도메인의 원본 개체에 다시 전달되지 않습니다. 추상적인 수준에서 이 시나리오는 클라이언트 브라우저에 의해 요청되는 정적 HTML 페이지의 시나리오와 유사합니다. 즉, 서버에서는 파일을 복사하고 스트림에 써서 보낸 다음에는 해당 파일에 대해 잊어버립니다. 후속 요청은 단지 다른 복사본에 대한 다른 요청일 뿐입니다.