CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Steve Hebert's Development Blog

Steve's Blog - From .Net to dotMath and everything in between.

March 2006 - Posts

  • Securing WSDL - first run

    I've been pretty happy so far with an implementation to secure my webservices using an IHttpModule to capture the SoapHeader early in the pipeline and authenticate before getting to the webservice call itself.  This eliminates the need to deal with authentication in each WebMethod call.

    Another area I'm looking at is securing the WSDL - since the WSDL request is not made using a SoapRequest, the mechanism has to be different.

    Right now, I'm considering hooking the ASMX request and looking for the ?WSDL parameter (https://myService/myService.asmx?WSDL).  I could then intercept the call and hand back a bogus/empty WSDL if authentication parameters are not specified.  If they add parameters for authentication, then I could hand back the real WSDL (https://myService/myService.asmx?WSDL&User=YaddaYadda&Pwd=BlahBlah).

    What's interesting is that I could use my permissioning bits to hand back a custom WSDL, but I'd rather not force someone to reacquire the WSDL if they purchase new capabilities. My feeling now is that leaving any messages about permissioning are best left up to the individual functions.

    I'll blog more as I move forward on the implementation.
  • Raw memory allocation speed - c++ vs c#

    I've had several conversations on OO languages in the past couple of months.  Going back to the migration from C to C++, developers became dependent on the 'new' operator and many times did so without understanding the consequences. In C++, 'new' = malloc() + non-inline function call (constructor). 

    So I started wondering - what are the performance differences between the C# and C++ new operators.  To test this, I intentially created a small class that gets allocated over and over.  To better compare the two languages since C# uses garbage collection, I intentially avoided the destructor call in C++.  Since I cannot avoid the garbage collector, I decided that best case C# won't have time to call the gc and worst case C# will be penalized for it.

    That said, I created the following code in C++. Keep in mind this is for the explicit purpose of isolating the function of allocating an object and calling a constructor.

    C++ code

    class OneInt

    {

    public:

       int i;

     

    public:

       OneInt()

       {

          i=1;

       }

    };

     

     

    int main(int argc, _TCHAR* argv[])

    {

       OneInt* oneInt = NULL;

     

       for( int i = 0;  i < 20000000; i++ )

          oneInt = new OneInt();   // intentional memory leak to avoid destructor call

     

     

       return 0;

    }

    C#  code

    class OneInt

    {

       public int i;

       public OneInt()

       {

          i=1;

       }

    }

     

    class Main

    {

       static void Main(string[] args)

       {

          OneInt oneInt = null;

          for( int i = 0;  i < 20000000; i++ )

             oneInt = new OneInt();

       }

    }

     

    The results you ask?  On a Pentium 4 3.2 ghz box...

    C++ averaged slightly more than 5 seconds to run.
    C# averaged .15 seconds to run.

    The +/- on both the C#/C++ code was less than .01 seconds, so I would consider that time to be TickCount resolution noise.

    Having this type of code in a production environment is unrealistic - or at the very least, diplomas should be revoked.   I'm not sure how much you can mark up to the organization of the constructor call IL, but I suspect the allocation of system memory in chunks larger than the requested object is playing into this.  That task of preallocating memory and handling your own allocation pattern in C or C++ is very non-trivial work when the need arises.

More Posts