yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
Cloud Expo & Virtualization 2009 East
Smarter Business Solutions Through Dynamic Infrastructure
Smarter Insights: How the CIO Becomes a Hero Again
Windows Azure
Why VDI?
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun's Incubation Platform: Helping Startups Serve the Enterprise
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Google SPDY Protocol Would Require Mass Change in Infrastructure
Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across n

Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across networks to support

ArsTechnica had an interesting article on one of Google’s latest projects, a new web protocol designed to replace HTTP called SPDY.

blockquote SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.

Having recently emerged from a trip into the world of service-providers and its associated protocols, the description of SPDY immediately brought to mind other asynchronous, message-oriented protocols such as SIP and DIAMETER. It therefore made me seriously consider the kind of massive changes that would be required to support such a protocol across all data center components: security, load balancing, acceleration, web servers, application servers, caches. Basically any network intermediary based on the premise of a strict request-reply, synchronous behavior would likely need radical changes to its core protocol handling systems.




SPDY, as described, is asynchronous and message-oriented. Like DIAMETER, SPDY would allow multiple requests per connection, effectively turning a single connection designed to be used and then closed into a long-lived connection. This is more along the lines of a SIP connection which is initiated and held open until the session is terminated.This is very different from the HTTP model in which connections are opened and closed within fairly short time intervals and are not expected to be held open for exceedingly long periods of time. SPDY thus eliminates the overhead associated with opening and closing many connections and the negative impact that has on application performance.

The current draft of the SPDY protocol states that “from the perspective of the server business logic or application API, nothing has changed”. But from the perspective of the infrastructure that needs to process the protocol, everything changes.


The following  are directly from the draft of the SPDY protocol and document the changes from HTTP to SPDY


    • The first line of the request is unfolded into name/value pairs like other HTTP headers.  The names of the first line fields are method, url, and version.  These keys are required to be present.  The 'url' is the fully-qualified URL, containing protocol, host, port, and path.
    • HTTP request headers are compressed.  This is accomplished by compressing all data sent by the client with gzip encoding.
    • Content-length is not a valid header.
    • Chunked encoding is no longer valid.


    • The response status line is unfolded into name/value pairs like other HTTP headers.  The names of the status line are status and version.  These keys are required to be present
    • Content-length is no longer valid.
    • Chunked encoding is no longer valid.

These changes would have a huge impact on infrastructure solutions, many of which rely on URI or HTTP headers (custom and standardized) to perform specific actions such as blocking, scanning, persistence (server affinity), or routing. The requirement that SPDY be transported via SSL has its own, well understood impact on infrastructure and is already dealt with by most devices, but SPDY also requires that headers are compressed via gzip. This means every intermediary requiring to perform some action based on the headers will need to decompress, process, and then likely recompress the headers before sending it on to the next hop. Coupling required compression with SSL would not only require support on all relevant infrastructure but will also likely reintroduce latency that could offset some of the performance gains claimed by testing of SPDY thus far.


    That all communication would essentially flow between the client and server over a single connection also poses a challenge for intermediaries that perform any kind of analysis or are required to act on the data exchanged. Load balancers, for example, are not generally designed to handle switching of messages in what becomes a 1:N connection:server scenario. The protocol could likely be supported as is by most load balancing solutions on a strictly layer 4 load balancing basis but advanced features that take advantage of application-aware capabilities such as message header and payload value routing (content-based routing) as well as egress functionality like Data Leak Prevention (DLP) would be much more difficult to implement, if not impossible for some solutions. This capability actually sounds a lot like HTTP pipelining on the request side.

    The single, long-lived connection would have more of an impact on the overall architecture and capacity planning. In some respects it would be easier, as there would be an easy 1:1 ratio between users and connections. But because each user is effectively being handed dedicated compute resources, this would actually change the resource consumption model on servers and make it more difficult to support high volumes of users without building out a scalable infrastructure.


    Further complicating the ability of infrastructure solutions to handle SPDY is its definition as asynchronous. Essentially asynchronous protocols do not enforce order of replies. That means a client could send three requests in a row without waiting for a response and the server could send back the response in a completely different order. Again, from the draft SPDY protocol:

    blockquote Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, it is important for clients and servers to interleave data messages for concurrent sessions.

    This may not sound like a problem, but for infrastructure that is optimized to handle HTTP and has been built around its implicit behavior this would require changes to the core networking stacks on most devices. In a typical HTTP scenario a request is received, the infrastructure solution processes any applicable ingress policies, and then initiates a connection to the appropriate server and waits for a response. It  appears that with SPDY, like DIAMETER, the infrastructure still processes any applicable ingress policies and initiates a connection but does not necessarily wait for a reply as it might need to act upon the next incoming message.

    This means a single network “session” would need to carefully track multiple incoming requests and outgoing responses at the same time on a per connection basis. This is not something most infrastructure is typically prepared to handle. Combined with the possibility that different requests may need to be routed to different servers within the infrastructure, this complicates the nature of application delivery and load balancing and could have a huge impact on the costs associated with cloud computing. Long lived sessions/connections initiated on secondary or tertiary servers launched to handle temporary capacity increases could hold open those connections long enough to incur excess charges that are unnecessary.


    Also similar to DIAMETER is the inclusion of a “real server push” feature. The ability of a server to act like a client and vice-versa is inherent in DIAMETER and this reverse flow of traffic is not something most infrastructure is prepared to process.


    Any infrastructure solution that is heavily focused on application layer (HTTP) processing for any purpose would likely need to make radical changes to its core networking and processing engines. Some solutions, particularly those tasked with load balancing and scaling existing message-based protocols may already be capable of supporting a protocol like SPDY. Whether the solutions that support DIAMETER and SIP load balancing and scalability could support SPDY without modification is highly dependent on whether support for the service-provider focused protocols is based on an underlying generic message-based implementation [PDF] or a protocol-specific implementation. The latter would be difficult to adapt to a new protocol while the former would be more easily extended to specifically support the requirements of new message-oriented protocols.

    But that’s only load balancing and scalability. There are many other infrastructure devices that are used to secure, monitor, accelerate, and otherwise manage HTTP that would need to be updated to handle such a new protocol. The upheaval across data centers would likely be on par with the anticipated challenges associated with mass migration from IPv4 to IPv6. Like that migration, however, support for both SPDY and HTTP could be achieved through the use of translating gateways; infrastructure capable of supporting both SPDY and HTTP or able to translate between the two could be utilized to enable a smoother transition.

    While it’s a fascinating and exciting notion, the introduction of a completely new protocol to replace HTTP seems more academic than realistic. More realistic would be for gradual implementation through adaptation of SPDY’s core concepts into the next generations of HTTP until HTTP is indistinguishably from a protocol such as SPDY. Making modifications and improvements to HTTP would be an evolutionary step rather than the revolutionary change implied with SPDY that would be almost too disruptive to adopt.

    That said, not everything that comes out of Google Labs is adopted as an industry wide solution. It’s an experimental environment and a good one at that. What may come out of the SPDY project may well in fact be changes to HTTP rather than the presentation of a new, radically different protocol. Regardless, SDPY and Google’s efforts have people talking about what’s wrong with HTTP and how it might be fixed and that conversation is one we’ve probably needed to have for quite some time now.

    You can read more about the tools Google offers and general problems with web performance at Google’s “Let’s Make the Web Faster” site.

Read the original blog entry...

About Lori MacVittie
Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Latest Cloud Developer Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions n...
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructur...
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mis...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performa...
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers