If you are UCMA API user, then you would like the msdn developer forum specific to Unified Communications Managed SDK. You can post all your UCMA API related questions on this forum http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1891&SiteID=1
In this webcast, we present the software development kit (SDK) for the Microsoft Unified Communications Managed API (UCMA) version 1.0. The SDK includes a SIP-based endpoint API that can provide the flexibility and scalability required by advanced developers to build and integrate server applications, such as alert broadcasters, media control units, and instant messaging (IM) bots, into the Microsoft Office Communications Server 2007 infrastructure.
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032343097&CountryCode=US
If you just started looking into UCMA API this webcast might be interesting for you. Its on-demand version is available on msdn site.
This posting is provided "AS IS" with no warranties, and confers no rights
Hi,
This might be a good news to all of you who were searching for the download pointer for UCMA API and difficulty in finding it. Now you can download it without logging into msdn account.
http://www.microsoft.com/downloads/details.aspx?FamilyID=1aaf0e4f-804c-4888-9c7c-81d7f7a6ddef&displaylang=en
I will start posting samples about API usage scenarios now.
This posting is provided "AS IS" with no warranties, and confers no rights
I was eagerly waiting since a long time to write about this exciting news, With the public annonucement of OCS 2007 beta, now we have a managed API known as UCMA is publicly available. Before coming out with official name UCMA, we were internally calling it as Ucp.net sdk. This SDK opens up the Sip signaling stack for managed application. As soon as it publishes on MSDN (expecting within a week or so), I will provide the download link and I will post more real scenarios and samples here.
Its a sip stack endpoint API, below is the list of some interesting features you will see in UCMA 1.0
a) Support for Sip Endpoint REGISTER to sip servers and SipPeerToPeerEndpoint,
b) Full SipSignalingSession to establish Sip dialog, it includes support for REDIRECT and REFER,
c) Utility classes for Sip header, Sip uri and SDP parsing,
d) Support for SIP SERVICE request, which is commonly used by OCS for publish operations,
e) Support for basic SIP Subscription dialog and Notification with automatic refresh,
f) Great scalability for middle tier application with MTLS server connection management,
In the coming weeks I will be posting simple code snippets and explain the usage scenarios for each of this feature.
This posting is provided "AS IS" with no warranties, and confers no rights
Since last few years I was reading a lot of discussion about "extreme programing" and "test driven development". I decided to explore and apply some of those principles in my own development and within my team. Here are some of the interesting things I would like to share. These experiences are based on a project for developing a public SDK.
Approach:
First thing I really did not try the hardcore methodology of test driven development. I took a little relaxed approach with relaxed restrictions.
My approach contains following category of pro-active and reactive actions.
a) Pro-active action was applied on all new functionality, here I did applied the rule that at minimum main line happy scenario code path must be included as an automated unit test and most common failure code path should be covered,
b) Second action is reactive approach, here when our test team reported any issue. Fix must include unit test and should also try to cover other related scenario.
In some sense this looks very relaxed compare to hardcore "test driven development" approach, but I found it is easy for adoption within the team and still contains lots of benefit in terms of time investments and returns.
Results from this approach:
Overall I was very encouraged with this approaqch and here are some of the fruits I found in applying this approach
a) Overall quality of regular build is improved with almost no regression in mainline scenarios.
b) Unit tests included with bug fixes helped to cover more related scenarios in addition to identified bugs.
c) Test team is more happy; unit test code snippets works as live spec document for them and help them to start testing right away.
d) Very few complaints from test team about missing or outdated specs.
e) Test team is very active in finding corner cases, fault injection, stress, perf scenarios and helped to provide better coverage and repro, which definitely improve the overall quality in eraly product cycle.
e) Writing the unit test for happy line scenario help us to exercise our scenarios as a real API user customer. This helps us to find API naming and usabilty issues even before including the public API in product.
f) We did keep test code and product code in separate assemblies, this helped to improve overall debuggability of the code.
Overall I found the approach was very practical and beneficial for us, I will post more details and some quantitative data later.
This posting is provided "AS IS" with no warranties, and confers no rights
If you are looking for adding cool instant messaging and presence functionality to your web applications or simple C# applications, try out Communicator Web Access AJAX Service SDK, it already includes the sample code to get started. I will also keep posting quick code snippets here.
Quick Info from the SDK:
Communicator Web Access AJAX Service is the application programming interface for Microsoft Office Communicator Web Access. Application developers can use it to create Communicator-compatible clients that allow users to manage and share presence information, to manage contacts and groups, to send and receive instant messages, and to search for users within an enterprise. Such clients can be a browser-based Web application (e.g., an ASP or ASP.NET application) or a standalone network application (e.g., a .NET executable). The client applications can be written in a wide range of programming languages including JavaScript, C#, Perl, C/C++, and the Visual Basic development system. Because the Communicator Web Access AJAX Service is based on the flexible AJAX programming model, the client applications are not limited to running on Microsoft Windows operating systems and can readily be deployed to desktop, laptop, or other devices.
Download Link:
http://www.microsoft.com/downloads/details.aspx?familyid=A839967B-680F-41E6-99B4-F020319BBD88&displaylang=en
This posting is provided "AS IS" with no warranties, and confers no rights
Finally the official RTM day for Communicator Web Access (CWA) is arrived, its pretty cool to watch the real time presence and IM to your contacts from web based application. For me it was very exciting to deliver my first RTC product in hands of the customer.
Its pretty cool application demonstrating the power of AJAX and it is 100% managed application build on .net frameworks 2.0. Ofcourse it also uses the power of my favourite System.Net classes of .net frameworks. UI is pretty much same as familiar office communicator 2005. It is useful for anyone working remotely or non windows machine. For Microsoft people it is already deployed (check => https im dot microsoft dot com), I found it very useful for communication, when I am sitting at home and not connected to my office machine.
To get more information and FAQ you can read Microsoft Office Communicator Web Access Overview
If you are looking for download check the Microsoft download center - Communicator Web Access download
One comment I can not resist to mention about UI, it is so much similar to office communicator 2005 :) that one of my friend even asked "How did it launch the office communicator on my machine and would it work on a machine with no office communicator installed." Only later he realize that it is browser window not the office communicator application.
This posting is provided "AS IS" with no warranties, and confers no rights
Actually the issue I am discussing here is in general true for any event handler. .net event handler are strong reference. In case of NetworkChange it become more important because both event handler on NetworkChange object are static handlers, so there life time is the lifetime of the process.
For example you may be using code like below for registering an instace method of your object as handler
NetworkAvailabilityChangedEventHandler myHandler = new NetworkAvailabilityChangedEventHandler (myNetworkAvailabilityChangeHandler);
NetworkChange.NetworkAvailabilityChanged += myHandler;
Then you should make sure to unregister event handler once you are done with this object, otherwise your object is not garbage and you will see a memory leak effect on your application
NetworkChange.NetworkAvailabilityChanged -= myHandler
Please note this cleanup code can not be put in finalizer (becuase object is not yet garbage), you need to explicitly call it.
Another option is to go with some sort of weak delegate. .net frameworks still do not have any concept of Weak delegates, but there are some cool solutions developed for simulating weakreference semantics, which will be very useful in this situation. These solution mainly consider using a proxy object standing between your object and final object where you want to register events. Check the Greg's blog Simulating “Weak Delegates” in the CLR for nice explanation and pictorial representation..
There are also some other slight improvement versions of same solution
Simulating Weak Delegates for EventHandler-like Delegates (Ian Grifiths)
Weak Events (Xavier Musy)
This posting is provided "AS IS" with no warranties, and confers no rights
When you are worrking on managed socket application and your application is very extensively doing send/recieve on the socket, then probably you need to care about understanding the heap management. Socket.Recieve or Socket.Send finally need to call the underlying native winsock API call to recieve the data on user specified buffer. Same is true for NetworkStream.Read and NetworkStream.Write calls, because these methods also finally got translated socket send and recieve.
To make the native API call buffer need to pinned for I/O, these pinned buffer can not be moved when garbage collector is doing the work of cleaning up. If your application is using newly allocated buffer in slow network environment and application is doing multiple I/O call frequently then it is possible that you will hit the problem of heap fragmentation. If fragmentation is small, you probably do not need to worry about it, but if heap fragmentation is reaching more than 10% and you are seeing larger time spend on GC. You need to look into some better techniques to elliminate the unnecessary pressure on GC. One possible solution is create a pool of buffer in the startup and use object pooiling to reuse them as needed.
Check the maoni's blog entry Using GC Efficiently – Part 3 to understand more about pinning and effective usage of GC and other good tips.
This posting is provided "AS IS" with no warranties, and confers no rights
Its long time since I had posted on my blog. I am coming back and will start posting regularly. One of the reason was I moved to the new feature area known as "Real Time Collaboration". You might have seen the release of Live communication server and office communicator release recently. Very soon our team would be releasing the web based version of communicator. All these are very exciting, cool part of web version is it is completely managed code and in the bottom of networking stack it uses the System.Net.
I will continued to post on Network Programming and would add topics on Real time collaboration and SIP in feature areas.
Recently one of the reader asked an interesting question, he was using FtpWebRequest with MakeDirectory method, if directory already exist then application received the WebException with message.
"The remote server returned an error: (550) File unavailable (e.g., file not found, no access).". This exception message appears to be very generic and not helping the user to figure out what causes this request to fail. The reason is exception messages are generally set by framework implementation, because they also need to be localized on different language versions.
In such case if FtpWebRequest user want to diagnose and figure out why request actually failed, he could access the actual response message from server using
((FtpWebResponse)e.Response).StatusDescription property. Your actual code would look like as below
try
{
. . . . . . . .
WebResponse response = request.GetResponse();
. . . . . . . . . .
}
catch(WebException e)
{
String status = ((FtpWebResponse)e.Response).StatusDescription;
}
This posting is provided "AS IS" with no warranties, and confers no rights
Last few weeks we were busy to get Whidbey Beta-2 bits ready for release.
If you are looking for some API where your application could talk to a FTP server, which supports SSL. FtpWebRequest under System.Net namespace is your solution. Here I will just point to SSL specific features of the class
Enabling FtpWebrequest to use Ssl is pretty simple, you just need to set EnableSsl flag before calling GetResponse() or GetRequestStream() on the FtpWebRequest object.
FtpWebRequest request = WebRequest.Create(ftp://myftpserver/dir/filename);
request.Method = WebRequestMethods.Ftp.DownloadFile;
request.EnableSsl = true; // Here you enabled request to use ssl instead of clear text
WebResponse response = request.GetResponse();
Some people asked me why FtpWebRequest support "ftps:" protocol based uri similar to "https:", the reason is there is no standard "ftps" scheme specified (yet) and ftp-over-ssl mechanism actually does not demand dedicated port for ssl, you could do it on the same server port on which you are doing regular clear text ftp. It depends on server configuration choice to force the SSL or allow both.
Once you start doing Ftp over SSL there are two important things you will need to know
Validating Server Certificate
If you were old WebRequest user, you might already know about using ServicePointManager.CertificatePolicy for https server certificate validation. In whidbey you will notice the compiler warning saying ServicePointManager.CertificatePolicy is obsolete and replaced with ServicePointManager.ServerCertificateValidationCallback which is delegate of type RemoteCertificateValidationDelegate. New delegate provide better programming model with all certificate errors reported in a single callback and you will also get instance of X509Chain object, which allow you to make decision on certificate chain.
ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(myCertificateValidation);
Actual method will look as below
public bool myCertificateValidation(Object sender,
X509Certificate cert,
X509Chain chain,
SslPolicyErrors Errors)
{ return (certificate.GetName() == "my_trusted_name"); }; //Just an example, not real world scenaio
:) Another additional advantage you can take with delegate is from anonymous method support of C# 2.0, especially if you have very simple 1-2 line certificateplicy to implement, see follwing example.
ServicePointManager.ServerCertificateValidationCallback = delegate(Object obj, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors)
{ return (certificate.GetName() == "my_trusted_name"); }; //Just an example, not real world scenaio
Using Client Certificate
Using Client certificate based authentication when connecting to FTP-SSL is no different then existing HttpWebRequest. You just need to assign appropriate X509Certificate instance to the request object before making GetResponse() or GetRequestStream() call.
This posting is provided "AS IS" with no warranties, and confers no rights
.Net frameworks 2.0 have new addition of Namespace, System.Net.NetworkInformation, it provide a number of interesting classes to extract the network related statistics and state of the machine, it pretty much provide most of the functionality which is exposed by native IPHelper APIs.
Earlier I had shown a simple example for getting network availbility event notification. Here is another simple 4 line example, where your application could check all the listening ports on the machine.
using System;
using System.Net;
using System.Net.NetworkInformation;
public class Test
{
public static void Main()
{
IPGlobalProperties ipGlobal = IPGlobalProperties.GetIPGlobalProperties();
IPEndPoint[] connections = ipGlobal.GetActiveTcpListeners ( ) ;
foreach(IPEndPoint ipe in connections)
Console.WriteLine("Listening IPEndPoint = "+ipe.Port);
}
}
When you are writing application to run as service or middle tier, which is using client certificates. You should not enable strong key protection during certificate installation.
Strong key protection is the way you are informing the system that whenever someone want to use this protected resource (client certifcate) then prompt me for the permission. In middle tier environment you really do not want this prompt, you really want to run your application unattended. In fact with .Net frameworks 1.1, SP1 you won't be able to use the certificate with strong key protection.
Check the posting from Kevin W. Hammond about his experience on this issue
http://blogs.msdn.com/kevinha/archive/2005/02/15/373254.aspx
This posting is provided "AS IS" with no warranties, and confers no rights
Hi,
If you have an application build on .net frameworks 1.0 or .net frameworks 1.1, which is using System.Net classes. If you want to make sure that your app works behaves as expected on 2.0 we could help.This would also enable you to contribute on our effort for application compatibility verification and make sure application works perfectly with 2.0 version of frameworks.
Here are some basic requirements
a) You are willing to share the app with us under NDA, application should be small to medium size that can be set up in less than a day on one or two machine
c) Please note this effort should not be considered as any official guarantee for compatibility, we will do best effort to verify and tell, if there is any breaking changes
This posting is provided "AS IS" with no warranties, and confers no rights
