Stena Drills Down to Reduce Bandwidth and IT Infrastructure Costs with Riverbed Steelhead Appliances

Riverbed Technology (NASDAQ: RVBD), the IT infrastructure performance company for networks, applications and storage, today announced that Stena Drilling, a leading global provider and operator of offshore drilling rigs and drillships, has deployed Riverbed Steelhead appliances and Steelhead Mobile at various onshore and offshore locations worldwide. The deployment has allowed Stena to avoid both a costly bandwidth upgrade as well as additional investment in IT infrastructure. At the same time, Stena has seen a 30x improvement in file download times and enhanced staff collaboration. Full Story…

URL: http://www.riverbed.com/company/news/press_releases/press_112309.php

Transport Layer Security – a novel approach

Transport Layer Security (TLS) is widely used in Secure Internet communication, especially for securing Web / HTTP traffic. TLS is a replacement for the Secure Sockets Layer (SSL) protocol, which provides similar protections. TLS provides cryptographic services to application traffic payloads in the form of data authenticity and optionally data confidentiality. Each pairwise (P2P) secure session maintains independent cryptographic state for that session, which can aggregate to a large amount of state held on TLS terminators / servers, when millions of TLS connections are terminating at the same destination or domain (e.g. ecommerce / banks / eBay /etc.). Furthermore because TLS operates at the application layer, all cryptographic operations are performed on large application buffers, which require reassembly of all network packet fragments before operating on that buffer. This results in the need to provision expensive TLS aggregators at the front of each domain providing secure web communications and the solution does not scale well with increase in demand.

In this video, researchers from Intel Labs demonstrate a novel approach for providing a cryptographic scale free TLS solution, which can scale with increase demand. This is achieved by using a cryptographic key derivation technique, where using a ‘master key’ and some identifiers located in the packet, we can dynamically compute unique session keys on a per packet basis, instead of storing individual session keys for each and every session. The technique essentially trades compute for storage, thus allowing a larger number of TLS connections to be supported to a given server / domain. Furthermore, by providing the cryptographic operations on a per-network-packet basis (instead of operating on application payload buffers), it allows early validation of data integrity, allowing bad packets to be rejected without having to wait until the application buffer is reconstructed and applying the crypto operations / buffer validation at a later stage of the network pipeline.

Comments (0)

URL: http://feedproxy.google.com/~r/IntelBlogs/~3/t6D-y-iJxpc/transport_layer_security_-_a_n.php

SQL Server 2008 – SQLCLR .NET Framework Version

Since SQL Server 2005 we have had the ability to write User Defined Types (UDT&aposs) and User Defined Aggregates (UDA&aposs) etc. with the C# programming language that are executed by the .net framework CLR that is loaded within the SQL Server process.

In SQL Server 2008 the latest service release of the .net framework CLR version 2.0 is loaded within the SQL Server process. Given that the .net framework 4.0 introduces a new version of the CLR, which CLR be loaded by SQL Server if both the 2.0 and 4.0 CLR&aposs are installed?

SQL Server 2008 and the forthcoming SQL Server 2008 R2 release, previously codenamed "Kilimanjaro", will both continue to load the latest service release of the version 2.0 CLR.

You might be wondering, what is the rationale behind SQL Server continuing to load version 2.0 of the CLR? Is it merely a healthy cautious attitude so existing UDT&aposs, UDA&aposs, etc. are not broken; or is it because additional engineering would be required to support the new CLR?

It seems the answer is actually a little of both.

With the .net framework 4.0 we now have the ability to load two or more distinct versions of the CLR within a single process. In previous releases of the .net framework, a process could only load a single instance of the CLR. Given this restriction the CLR team recommended that hosts, such as SQL Server, use the LockClrVersion function to determine the version of the CLR to load prior to initialization. So, as stated previously, SQL Server 2008 and SQL Server 2008 R2 will continue to load the latest service release of the version 2.0 CLR as the version is locked before initialization of the CLR begins.

While future versions of SQL Server may load newer versions of the CLR, or even support the loading of multiple CLR&aposs within the process, version 2.0 of the CLR is here to stay for SQLCLR within SQL Server 2008 and SQL Server 2008 R2.

If you&aposre looking for more information on programming within SQL Server using the .net framework you should read Pro SQL Server 2005 Assemblies by Robbin Dewson and Julian Skinner. Other great books with content related to SQL CLR include Inside Microsoft SQL Server 2008: T-SQL Programming by Itzik Ben-Gan and Programming Microsoft SQL Server 2008 by Leonard Lobel, Andrew J Brust, and Stephen Forte.

Within the SQL Server 2008 Management Studio you can determine the current CLR version by executing the following query against the sys.dm_clr_properties view.

select * from sys.dm_clr_properties

Views are also available within SQL Server 2008 to determine information regarding the application domains, loaded assemblies, and tasks. The results of executing these queries can be seen in Microsoft SQL Server Management Studio below.

select * from sys.dm_clr_appdomains
select * from sys.dm_clr_loaded_assemblies
select * from sys.dm_clr_tasks

URL: http://feedproxy.google.com/~r/IntelBlogs/~3/jTZ_UpE3W1E/