Cart
[Home] [By Thread] [By Date] [Recent Entries]
> ...but if you're going to use TCP for RPCs, for God's sake don't use port > 80; that's for transferring hypertext. We have 65,000 or so port numbers > to choose from. If we use different port numbers for different things, > firewall administrators can make networks secure by controlling what does > and doesn't get let through. If Web browsing and RPCs all go over the same > port, then it's hard to disallow or control RPCs without affecting web > browsing. It's a cat and mouse thing: more and more applications use port 80/HTTP because firewall admins only allow web browsing. In return, firewall admins move towards application level firewalls (aka proxies) instead of simple packet filters. So in the end, both writing applications that are supposed to go through firewalls and firewalls that disallow these applications become more and more complex and, in general, a bit pain. > We use HTTP for RPCs, anyway? Being able to reuse Apache isn't a great > win. It's easy to listen on a port, perform some kind of authentication on > incoming connections, then just choose a scheme for delimiting requests > and an error-signalling system for use in response. Voila! Well, it may well be simple to implement this, but don't you think it's reinventing the weel all over again? There are very rugged HTTP implementations available on really all important platforms and ready for deployment today. Does anyone have numbers on how much bandwidth is wasted in HTTP? Also, there's a lot of nice features, like SSL-encryption, that you get for free when using HTTP. --------------------------------------- Stefan Zier Software Developer Syntion AG - http://www.syntion.com Leonrodplatz 2 - 80636 Munich/Germany Phone +49 89 52 30 45-0 Fax +49 89 52 30 45-20
|
