Slashdot Mirror
A New Protocol For Faster Web Services?
Roland Piquepaille writes "Jonghun Park is an Assistant Professor of Information Sciences and Technology at Pennsylvania State University. He says that a new protocol can improve Web services. Sandeep Junnarkar broke the story. "Jonghun Park proposed a method for sharing information between systems linked on the Internet promises to speed collaborative applications by up to 10 times the current rates. The protocol is based on an algorithm that lets it use parallel instead of serial methods to process requests. Such a method boosts the efficiency of how resources are shared over the Internet. The new protocol is called Order-based Deadlock Prevention Protocol with Parallel Requests." Check this column for some excerpts or read the CNET News.com article for more details. More information about Jonghun Park's works can be found at his homepage."
Wasn't this reportedly the theory behind the Irish Young Scientists Xwebs project?
I could find nothing about it on that dude's homepage, and the article is terse to say the least. Where's some actual information about this?
Daniel
Carpe Diem
Putting the entire story in the slashdot posting is an interesting solution to the slashdot effect. Of course the content is a little more bland....
I'd prefer if the article we picked had some actual information about the protocol... off to google....
won't that make things more unsafe/unstable too?
because http is plain simple, it is easy to determine where resides what functionality.
if systems become more connected and integrated into each other, won't that make it much harder to determine what is going on on your system?
i can imagine that msft will have a go at running parts on your system on their registration servers. this seems to me like another step towards DRM.
i understand that this is just a protocol, but if people will start interconnecting systems, there will be (security issues)++
Int
Jonghun Park is an Assistant Professor of Information Sciences and Technology at Pennsylvania State University. He says that a new protocol can improve Web services. Sandeep Junnarkar broke the story. "Jonghun Park proposed a method for sharing information between systems linked on the Internet promises to speed collaborative applications by up to 10 times the current rates. The protocol is based on an algorithm that lets it use parallel instead of serial methods to process requests. Such a method boosts the efficiency of how resources are shared over the Internet. The new protocol is called Order-based Deadlock Prevention Protocol with Parallel Requests."
First, there is this whole climate fuelled by RIAA/MPAA that makes the very mention of collaborative applications something criminal.
Secondly, if there is to be a non p2p media sharing usage for this protocol, it has to get industry support. Read M$.
This looks like a solution looking to solve a problem that doesn't exist. Where have we seen this before?
Maybe you should actually read what you link to. As was pointed out several times, the article was based on *assumptions* regarding *inconclusive data* made several *years* ago, by a person who admitted that they *didn't* know much about what they where talking about. And further more, those people who did not ready to blindly board the anti-MS bandwagon the second it appeared, actually did testing to verify whether that theory held any water. Guess what, it didn't. IE was shown to operate in a completing normal manner.
The open source movement would be a lot better off if it *didn't* have the "support" of parrot mouth lamers who spout off the "MS bad, Linux good" line before they even know what is going on. Quality over quantity people.
This is cool and schmool, but where exactly are the collaborating applications that need to share and lock resources across Internet? Locking is useful only in preventing concurrent access to a critical nondivisible resource. Of course, web browsers share servers, but they don't need to lock them (well, sometimes they "lock" them, but this is only a side effect known as "slashdotting"). P2P apps? I don't think they need to lock anything in order to share files.
A-ha! Web services! Ok, what web services? Have you ever used a distributed web service application that needed to lock resources? I thought so.
I am not saying that this protocol is bogus, but it will probably be useful for apps that don't exist yet, at least on the Internet.
Park said that he will seek to commercialize the next generation of his protocol that he has been fine-tuning over the past year.
Why? Didn't he look at HTTP at all? The reason it was so successful and widespread was because Tim Berners-Lee did not commericalize it. If Park makes this protocol commercial, it will either not be adopted at all, or it will be bought and proprietized by Microsoft. Neither of those are particularly desirable. If he keeps it open and free, it could eventually garner as much popularity as HTTP. Tis too bad he cares only for getting a check.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
Most developers of enterprise systems don't need this. Traditionally, the bottleneck of data driven medium-to-big apps is the database; Connecting, connection pooling, reading, caching, whatever.
.NET has similar bottlenecks, but I don't know, haven't worked with it.
I'm working on a large web-services product/project now using various J2EE technologies (JRun, Castor, Object Relational Mapping, Axis) and my biggest bottlenecks are the database (problem mostly solved through caching, and clustered caching), XML Serialization/Deserialization or marshalling/unmarshalling (problem solved using Castor XML) of the object graph to and from the SOAP body and Java objects, and simply the passing of large object graphs through XML protocols like soap.
Go read the server-side.com, or Bitter Java, they'll tell you what the common bottlenecks are, and this usually isn't one of them.
I assume
--Stupidity is Self Curing!
Absolutely. And the mark of a brilliant scientist is one who sees how to transfer existing knowledge about one domain into another.
That being said, I highly doubt that Park's research has much to do with database mutexes. The courses I've taken in concurrency pretty much left me baffled. There's a lot more to it than thread safety.
So long, and thanks for all the Phish
HTTP was designed to be efficient for cases where a relatively simple request is going to result in a relatively large result dataset. Distributed services don't follow that pattern. You often have a relatively complex request (save changes to customer information) producing a simple result (changes saved/lost.)
HTTP also was also designed as a stateless protocol, and does not have the facilities to ensure any time or order based serialization of requests and results. (Yes it can be cobbled in via back-end stateful servers and session context data, but it isn't used by the HTTP server itself to serialize anything.)
Abusing a simple protocol in order to make life "easier" for the network configuration and administration team is just a bass-ackwards way of dealing with things. Networks are an infrastructure service for providing information systems to business, as are databases, file servers, application servers, programming services, etc. Nothing ever seems to end up "easy" except with a loss of functionality, efficiency, or scalability.
I do not fail; I succeed at finding out what does not work.
Great, so you can handle 10 simultaneous web requests. That might decrease the latency for a client, but it won't increase the performance of your server. Just the opposite, it will degrade it as the same number of client requests now generate 10 times as many connections. With each connection consuming threads and traffic, say bye-bye to your rock solid web server.
This is an example of research without grasp of reality.