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."

9 of 131 comments (clear)

  1. Order-based deadlock prevention? by Anonymous Coward · · Score: 4, Insightful
    Oh, how original.

    Anybody who's done real database engineering knows the two points necessary to prevent deadlocks: (of course, most designers/programmers don't do this...)

    1. Every process locks resources in the same order.

    2. No process ever escalates a lock.

    Enforce these two adages ruthlessly and you'll never get a deadlock.

    So all this guy is saying is "Engineer your distrubuted databases properly." Woot.

    1. Re:Order-based deadlock prevention? by Anonymous Coward · · Score: 1, Insightful

      I think it is more about a generalized proposal for dealing with concurrency at the service level, such as step-1, step-2, step-3, ... which can be done in parallel across multiple machines, ...etc. Anybody who has dealt with software construction (ala concurrent make) would understand.

  2. Pipelining by Karamchand · · Score: 2, Insightful

    That's called pipelining, right? We already have this in various protocol, including HTTP which is used quite frequently for various web services (think SOAP)

    1. Re:Pipelining by Anonymous Coward · · Score: 1, Insightful

      How about you read the entire paragraph of 8.1.1? The jist is that opening multiple TCP connections to a server increases network congestion and is largely unneccesary given that most HTTP responses have a relatively small payload. The pipelining referred to means sending multiple requests on a TCP connection without waiting for a response from the server. Look at the sentence right before the one you quoted: "HTTP requests and responses can be pipelined on a connection". Also, take a look at the sentence you quoted yourself: "allowing a single TCP connection to be used more efficiently."

  3. Is this really the job of the protocol? by CrazyJ020 · · Score: 3, Insightful

    "The proposed protocol is free from deadlock and livelock, and seeks to effectively exploit the available alternative resource co-allocation schemes through parallelization of requests for required resources,"
    This article is useless. This quote is the only information that is remotely informative in the entire article.

    And to get to my point, the management of resource access is hardly the job of the protocol. It is the job of the underlying web Service implementation to deal with these issues. Why should the protocol even have knowledge of the the resource state?
    1. Re:Is this really the job of the protocol? by GreyPoopon · · Score: 3, Insightful
      Why should the protocol even have knowledge of the the resource state?

      I think providing the protocol with this knowledge is supposed to speed up the whole process while still preventing dead/livelock situations. However, as you said, the article is way too barren of any real information to assess how this is really supposed to happen. It may be intentionally devoid of details until the authors of this protocol determine whether or not they really "have something."

      --

      GreyPoopon
      --
      Why is it I can write insightful comments but can't come up with a clever signature?

  4. Re:HAHAHAHAHHA by jhol · · Score: 2, Insightful

    You got it all wrong, you need to look at the context of the quote.

    What he meant by that is that the deployment of web services is held up by security and reliability, this has nothing to do with performance. Everyone that has worked with web services know that web services are not up to date with security and reliability yet, but it is being worked on. And this is what is keeping web services from being used on a broader scale.

  5. Re:Yeah, whatever... by tlianza · · Score: 2, Insightful

    Since many (if not most) applications for Web Services are b2b, the speed of your modem is fairly irrelevant. When you pull up sometravelsite.com, it will be gathering information from other systems more quickly -from it's servers to other servers- and the web service communication portion of the architecture doesn't run over your last mile at all.

  6. Re:RTFA by Anonymous Coward · · Score: 1, Insightful
    It's the same phenomena. Just substitute "data store" for "database". If the data requests against the data store aren't concurrent, they can't deadlock no matter what the damn target happens to be named.

    And just because it's been published doesn't mean it doesn't boil down to "build your infrastructure correctly, and enforce your design constraints".