I suppose I should explicitly mention, if it wasn't obvious from my description, this means that it all depends on how you interpret "using tcp with IIS".
If your server code is behind a firewall that only allows http traffic through port 80, and all the clients are on the "other" side of the firewall, then you "can't use tcp with IIS", because IIS will only handle http traffic. If, OTOH, your server code is behind a firewall that only allows http traffic through port 80, but some clients are outside the firewall while others are inside the firewall, then those clients outside can use http to get to your server, while those inside the firewall could use tcp to talk to the same object. And if, like me here in my home office :-), you can arbitrarily pick ports (or your admin will agree to open one) then you could do what I did and allow anyone to use http or tcp to get the same object. -Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Mike Woodring" <[EMAIL PROTECTED]> To: "dotnet discussion" <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 10:40 AM Subject: Re: Re: [DOTNET] Remoting on Tcp and Http > Technically speaking, you're not really "using tcp with iis". IIS/ASP.NET > is just providing a process to host your code in (aspnet_wp.exe). The > method call messages are taking different routes to get to the client & > server. The picture looks something like this... > > INETINFO.EXE, bound to port 80, handles incoming http requests and, > recognizing the .soap extension, routes the request to aspnet_wp.exe via > named pipes for ASP.NET to handle. > > ASPNET_WP.EXE is hosting the server dll being invoked and, as a result of > parsing web.config using RemotingConfiguration.Configure, also contains an > instance of the tcp channel that's listening on port 8080 (in my example). > > So remoting requests from the client routed over http are sent to INETINFO > on port 80 on the server machine, which passes the request over to > ASPNET_WP.EXE to handle. The IHttpHandler for the .soap extension then does > its thing to route the method call request to the object. Remoting requests > from the client routed over tcp, on the other hand, go directly to > ASPNET_WP.EXE on port 8080, where they're handled by the remoting > infrastructure in the normal fashion without the side-trip through IIS. > > -Mike > http://staff.develop.com/woodring > http://www.develop.com/devresources > > ----- Original Message ----- > From: "Peter Laan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, April 12, 2002 10:27 AM > Subject: Re: [DOTNET] Remoting on Tcp and Http > > > > So you can use Tcp with IIS? I found some messages in the archives that > > seemed to say that it didn't work. But I'll give it a try. > > > > http://discuss.develop.com/archives/wa.exe?A2=ind0112C&L=DOTNET&P=R31947 > > > > Peter > > > > From: "Mike Woodring" <[EMAIL PROTECTED]> > > > If you're using IIS/ASP.NET to host your remoting component, then just > add > > > an extra channel element to your web.config and the client configuration > > > files so that the tcp channel is registered on some port in addition to > > the > > > http channel. > > > > > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
