Monday, May 29, 2006

Well, I’ve been using realvnc (www.realvnc.com), and I think it’s neat. Now granted, I’ve only used it on my local network, which is a workgroup and not a domain; but I like it much more than the Remote Desktop that comes with Windows XP.

The reason I like it better than Remote Desktop is because I can share a desktop among more than one computer. I run Windows XP Pro SP2, and I’ve found that when I connect to another computer with Remote Desktop, my local computer logs off.

What I want is to share a program with multiple computers. You know, I’m running an app and I want three or four friends to also see that app. In fact I want more than that … I want those three or four friends to be able to take control of my app – click a checkbox or click a button. I can do this with realvnc.

We have used gotomeeting (www.gotomeeting.com) for this. Gotomeeting is a great program and works fine over the Internet. And I haven’t tried realvnc over the Internet. I think the cost of gotomeeting is reasonable. It’s about $50/month, but realvnc has a free version.

There are for-pay versions of realvnc. On their website you can compare features. The personal edition does encryption and file transfer along with some other features that I don’t understand like “one-port HTTP & VNC” and “Desktop Scaling.” The cost is reasonable (about $30 for each server site). I have not tried running the viewer on a site that does not have the server.

Gotomeeting has a messaging capability that realvnc lacks (or I haven’t found it.) This is not a big loss for me. We like to use Skype (www.skype.com) for voice communication anyway. BTW, Skype works really well over broadband and over the free wireless I can pick up in various coffee shops, but it worked terribly with PeoplePC. I had dialup PeoplePC for a while and was not impressed with its performance and got somewhat irritated with its silly user interface.

When I first started using realvnc, I was not able to share a desktop with several computers. When another viewer connected to my VNC server, the computer with the previous view lost its connection. Easily fixed, though, you got to configure the VNC viewer to have a shared connection. To do this open the viewer and click on Options before you connect to the VNC server. Then, under the Misc tab, choose “Shared connection…”

 

Here’s a screenshot of one of my computers running the viewer and connection to another of my computers running the server.

 

Now admittedly I have not tried this over the Internet yet. I don’t know what kind of problems firewalls and NAT routers will give me, but so far I really like realvnc.

Anyone else using it?

5/29/2006 3:04:17 PM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [4]  |  Trackback
 Friday, May 05, 2006

All the different .NET Remoting varieties have similar but not identical configuration files. And there are a lot of optional elements I am not showing. My description here is by no means complete. (For a full description of remoting configuration files, see the MSDN article Format for .NET Remoting Configuration Files – a good article, but could use more examples.)

What I’m trying to do is clear up some of the simple stuff for myself. So if someone sees an error here, I really would appreciate knowing.

Remote objects can be CAOs or SAOs and when they are SAOs, they can be singleton (stateful and all clients share state) or single-call (stateless). CAOs are stateful , and each client has its own state.

SAO (server side)

On the server, the config file looks like …

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.runtime.remoting>

    <application>

     <lifetime>

     </lifetime>

      <service>

       <wellknown mode = "Singleton"

        type = "StepByStep3_1.DbConnect, StepByStep3_1"

        objectUri="DbConnect" />

      </service>

      <channels>

       <channel ref="tcp" port="1234" />

      </channels>

      </application>

   </system.runtime.remoting>

</configuration>

 

Well, that you have a <service></service> element tells me that this is a config file on a server. <wellknown … /> tells me that it is an SAO; the mode attribute makes it a singleton.

This file chooses a tcp channel, but it could just as easily been an http channel.

Often for examples, I just create a console application as a simple server to host the remotable class. I could instead run the server process as a Win service or use IIS as an activation agent for the server process.

If you wanted to use IIS as an activation agent, the channel would have to be http.  Also, the objectUri value would have a .rem extension. My server would be a web app and the configuration would be in web.config. I would not specify a port number because IIS automatically uses port 80. I wouldn’t have a <channels></channels> element either. My web.config would look like …

<configuration>  

 <system.runtime.remoting>

  <application>

   <service>

    <wellknown mode="Singleton"

     type="StepByStep3_10.DbConnect, StepByStep3_10"

     objectUri="DbConnect.rem" />

   </service>

  </application>

 </system.runtime.remoting> 

<!-- other web.config stuff -->

</configuration>

 

SAO (client side)

On the client side, the config file (for the app that uses the remote object) looks like …

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

 <system.runtime.remoting>

  <application>

   <client>

    <wellknown

     type = "StepByStep3_1.DbConnect, StepByStep3_1"

     url="tcp://localhost:1234/DbConnect" />

   </client>

  </application>

 </system.runtime.remoting>

</configuration>

 

That you have a <client></client> element tells me that this is a config file on a client. <wellknown … /> tells me that it is an SAO; there is no mode attribute because the client does not care about the mode.

Note that the value of the url attribute ends with the objectUri of the server-side config file. It also specifies the name of the computer that hosts the remote object and the port it uses. This example uses a tcp channel, but it could just as easily have been an http channel.

However, if you’re using IIS as an activation agent, the channel would have to be http. The url attribute value would end in .rem. And I would not specify a port number.

CAO (server side)

On the server, the config file looks like …

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <system.runtime.remoting>

    <application>

      <service>

       <activated

        type = "StepByStep3_1.DbConnect, StepByStep3_1"

       />

      </service>

      <channels>

       <channel ref="http" port="1234" />

      </channels>

      </application>

   </system.runtime.remoting>

</configuration>

 

That you have a <service></service> element tells me that this is a config file on a server. <activated … /> tells me that it is an CAO; there is no mode attribute because the client does not care about the mode.

CAO (client side)

On the client side, the config file looks like …

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

 <system.runtime.remoting>

  <application>

   <client url="http://localhost:1234">

    <activated type="StepByStep3_1.DbConnect,StepByStep3_1" />

   </client>

  </application>

 </system.runtime.remoting>

</configuration>

 

That you have a <client></client> element tells me that this is a config file on a client. <activated … /> tells me that it is an CAO; there is no mode attribute because the client does not care about the mode.

IIS does not support CAO.

 

5/5/2006 10:16:00 AM (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [4]  |  Trackback