We have plenty of socket servers here already.

Post #122,007 by admin 10/20/03 12:06:09 PM Reply	We have plenty of socket servers here already. I'm looking more for reasons not to do HTTP as well, I guess. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,012 by boxley 10/20/03 12:24:11 PM Reply	Sockets can stream, http does not, its connectionless so overhead will be higher using http and streams are faster. thanx, bill "You're just like me streak. You never left the free-fire zone.You think aspirins and meetings and cold showers are going to clean out your head. What you want is God's permission to paint the trees with the bad guys. That wont happen big mon." Clete questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #122,017 by admin 10/20/03 12:46:07 PM Reply	HTTP 1.1 supports pipelining, FYI. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,022 by folkert 10/20/03 1:12:26 PM Reply	YALOP Yet Another Layer of Processing. Okay... You could have http read the socket and send over the data over http. But why, why would you add another layer of processing. http has to be generated... gads adds tremendous complexity without any benefit of making things more robust. Complexity is nice, but only to a point. Me personally http was designed for one thing: a presentation transfer layer, it has lots of overhead and rides on top of TCP/IP. I akin this to electroncis... a transformer to be exact. A transformer is used to "isolate" or to multiply or divide (Voltage or Current). Theoretically they are supposed to be 100% efficient. In the real world, they can be as good as 98% but as bad as 50%. IOW, you lose much power just by adding a layer. The part that applies here is the Isolation. Or think of it as someone "expanding" your data, so it can travel over http. The only real help would be using an http server that compresses on the fly... of course a socket server can do that too, easier too as it doesn't have constraints placed on it by another process or service. "More work up front" usually mean "A lot less work down the road" which is usually a ++... to the good. http (specifically IIS) is a seriously moving target... if you can STOP any changes from happening... you could go that route but even Apache (or Weblogic, or WebSphere, or Roxen etc..)are still moving the specs around and break things from time to time. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* No, not here, not this time...
Post #122,026 by deSitter 10/20/03 1:19:38 PM Reply	Agreed The rexec (rsh, rlogin...) code should provide a speedy framework for setting up as complex a c/s system as you want. If all that is needed is to pull results from a calculation, you could just use r-commands in the first place. -drl
Post #122,766 by tablizer 10/24/03 11:06:10 PM Reply	Why not HTTP? I'm looking more for reasons not to do HTTP as well, I guess. What is wrong with HTTP? Anything else and you risk fire-wall problems. Server admins don't like special requests for "odd ports" at many companies. Simply use POST to send XML or comma-delimited text. ________________ oop.ismad.com
Post #122,775 by admin 10/25/03 12:19:08 AM Reply	Read the problem description. No firewalls are involved. While you are correct that firewalls preclude anything other than HTTP for the most part, this is entirely internal on our LAN. If you want to have real fun, try building a bi-directional persistent comm link between a client browser and an internal server through a firewall, when the internal server is actually a load-balanced non-clustered web farm. ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #122,825 by tablizer 10/25/03 5:13:44 PM Reply	You didn't qualify "too much overhead" Nothing is going to be an exact match to your desired performance or interface requirements. If you are sending streams of a gazillion little transactions, can some of them be grouped together so that packet overhead is less? Or, does each one need a reply before the next one is sent? These details are left out. ________________ oop.ismad.com
Post #122,828 by admin 10/25/03 7:36:35 PM Reply	Packet overhead doesn't matter. Computational overhead does matter. The transactions are uncoupled. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!