次の方法で共有

RPC Over HTTP Woes...

  • [アーティクル]

I spent the last two weeks in Europe, first at TechEd Europe in Amsterdam and then back home in the UK. To stay in touch with the goings-on back in Redmond, I used Outlook’s “RPC over HTTP” feature (side rant: I don’t know what marketing wizard came up with that name but surely they could have come up with something a little less cumbersome and implementation specific – I mean it’s like calling the World Wide Web the “HTML over HTTP with a smattering of JScript and DHTML Web”).

Anyway, this feature is supposed to allow me to use Outlook to sync my email and calendar from outside the firewall, connecting to the Exchange server using HTTP. Before the advent of the imaginatively named RPC over HTTP (I’ll call it RPCHTTP for brevity from now on J), you would have to use Outlook Web Access in these situations. Now that would of course mean you were in thin-client land and therefore would have no access to your email and calendar when you were offline, and you would have to make do with less than stellar responsiveness.

So, RPCHTTP was supposed to solve this problem by giving you the benefit of a fully featured smart client with the ability to access the Exchange server from outside of the firewall. Actually, RPCHTTP works really well most of the time, but given my experiences over the last two weeks, I am a little less impressed with RPCHTTP than I once was. Let me explain…

Despite having a broadband connection at TechEd Europe, the network was very busy and so the connection was extremely slow. In the UK, I was using a 56K modem and had the same problems – the connection was so slow that RPCHTTP refused to work reliably and either kept dropping the ‘connection’ to the server or it just sat there for hours on end with no apparent progress and a frozen user interface.

Part of the problem seems to be that Outlook uses an RPC mechanism to communicate with the server (I’m just guessing here J). Any RPC mechanism tightly couples the client to the server and often uses a chatty protocol – frequent but small calls between the client and server. This is not good over a slow connection.

Another problem is that Outlook does not seem to treat network communication fully asynchronously with respect to the user interface. It’s true that most communication seems to occur on a background thread, but some at least seems to occur on the UI thread, or the UI thread is suspended waiting for an asynchronous call to complete. Either way, Outlook often freezes up and no amount of clicking the “Cancel Server Request” option on the taskbar icon will bring it back. I wouldn’t mind if it took an hour to synchronize as long as I can carry on writing and reading email during that time. I wonder if this problem was missed because RPCHTTP was always tested on a reasonably fast connection.

Another problem is that Outlook does not seem to give you many options to filter the email and other artifacts that get synchronized. Two examples are the address book and large email attachments.

I have not yet found a way to tell Outlook not to synchronize the address book when I am out of the office. I of course run the risk of having an out of date address book, but faced with the prospect of downloading an address book over a 56K modem link when I know that I am not going to use 99.99% of it, I would be prepared to take this risk.

Outlook can download email headers when it thinks it is using a low bandwidth connection. In this case, you get the first two lines of the email and then you can opt to download the rest of email if it looks interesting. If you want the email body but not the 7MB attachment, then you seem to be out of luck – you either have to download the entire message or delete it.

I hope somebody who understands the innards of Outlook can put me right on these last two points – if you know how to fix these two problems, please tell me!

I admit that it’s difficult to anticipate all the different environment conditions in which the client will be used, but surely RPCHTTP was designed for people who are out of the office and who can only connect through a low bandwidth connection, say from a hotel room using a modem, or from a busy conference using a shared connection.

If you are designing smart client application which is to be used in similar circumstances, then it’s probably worth bearing in mind the following three points so you can avoid the problems that I have experienced with RPCHTTP…

  1. Consider what experience you want to provide for customers using a slow connection. The UI should never freeze and the user should feel in control at all times. It may not matter that transmitting and receiving data is slow as long as the user is aware of progress and can continue working.
  2. Give the user the ability to customize the application’s behavior according to the quality of the connection. If the user can prioritize what data needs to be transferred they can ensure that whatever bandwidth is available is used in the best possible way.
  3. Test your client using a very poor quality connection. Build this scenario into your test plans so you can see what the experience will be like. Even if your application is designed to be used exclusively on a supposedly high bandwidth connection (which you probably won’t be able to guarantee) it should scale back functionality gracefully when the speed of the connection drops.

Comments

  • Anonymous
    July 12, 2004
    I almost don't dare asking this: You are using cache mode, right?
  • Anonymous
    July 12, 2004
    Yes - I was using cached mode :-)
  • Anonymous
    August 08, 2004
    Thanks heaps for this.

    Im currently thinking about setting up HTTPRPC instead of Outlook Web Access for our roaming consultants.

    Do you think HTTPRPC is better than OWA....?
  • Anonymous
    August 08, 2004
    A lot better, notwithstanding my minor grips above.

    With Outlook and HTTPRPC you can at least continue to work when you are not connected, and if you have a reasonably fast connection you probably won’t experience the problems I talk about above. OWA suffers when you have a low bandwidth connection too, and you have to suffer a web interface even with a fast connection...
  • Anonymous
    June 16, 2009
    PingBack from http://topalternativedating.info/story.php?id=3248