I have an application that uses binary formatting over http. I recall having some issues getting it working and debugging was a pain, but it's been going strong for about 2 years now.
Jacob A. Grass -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Pardee, Roy Sent: Monday, August 29, 2005 12:17 PM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Reasons to use HTTP remoting I have this vague memory of reading that the remoting channel you use to pass packets back and forth (http or tcp) is independent of the formatting of that data (text or binary) and that that meant you could use the binary formatter w/an http channel & get something like the best of both worlds. Am I making that up? (That was on .net 1.1 mind you--I believe 2.0 is going to be way different...) -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil D Sent: Monday, August 29, 2005 10:09 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Reasons to use HTTP remoting I've heard http remoting described as "firewall friendly" because it's text-based, presumably because there are firewalls (or filters) that can be configured based on text in messages. I suspect that being able to see the data might also give network administrators some sense of security. Phil Wilson -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Davy J Sent: Monday, August 29, 2005 9:32 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Reasons to use HTTP remoting inline On 8/29/05, Franklin Gray <[EMAIL PROTECTED]> wrote: > Binary remoting is faster then HTTP remoting, but there are times when > HTTP is required. I want to make sure I got this part right. > > 1) It is required when going through firewalls, correct (without > opening up dedicated ports)? Not required but a lot easier > 2) Although not required, it is helpful to use HTTP remoting to > utilized the security functions of IIS, correct? Only if not going through a firewall, > > Our app will be running within our intranet. I'm not sure if that > means it's all within a firewall or not but I think it will be. Depends on the size of your company, ours has multiple home domains all seperated by firewalls so best to ask a network admin on that one. > > I used to use remoting for a DotNet client to a DotNet server through > the internet or in cases where the client couldn't access the DB > server. If I don't need to go through a firewall, then with the power > of client machines today and a lot of users of the system, wouldn't > the application run faster with having the middle-tier on the client > machine assuming the client can access the DB server (clients don't > bog down the server's memory)? The balance between cached central data and client side business logic, can only be decided on if you know how the company operates, we could give you ideas, but it comes down to the use of best fit for the schema and not a Recomended structure. imo. Davy J =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
