THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Tibor Karaszi

Endpoints, Netlibs, IPC and stuff...

Its been a while since my last post. No special reason, just a combination of lot of work and I didn't feel I had something pressing to say...

This topic is basically on how the client app communicates with SQL Server. Not the API level (like ADO or ODBC), or the packet level (TDS), but in between. Basicaly we're talking IPC, Inter Process Communication - in a SQL Server context:

Here's how I understand it (I probably gonna get some points wrong and you are all welcome to correct me):

There are network protocols, such as:

  • TCP/IP (has routing functionality of course)
  • NetBEUI (very limited, if any, routing functionality)
  • IPX (the original protocol for Novell networks)
  • SNA (mainly used in IBM mainframe and such environments)

A network protocol is of little use if we can't send data back and fort between application over that network protocol. So, there are APIs to facilitate IPC:

  • NETBIOS (originally developed for NetBEUI, but is also supported over IP (requires WINS or LMHOST for name resolution))
  • Sockets (not available for NetBEUI AFAIK, only TCP/IP)
  • Named Pipes (built on top of NETBIOS)
  • RPC (implemented and available over both NetBEUI and IP)
  • SPX (as I understand it, the API over IPX)
  • APPC (program-to-program protocol over SNA)

When MS released "their" SQL Server, they needed a way for the client app to communicate to the server. They decided to go for Named Pipes and developed what we call "netlib". I.e., the MS deveopers used the Named Pipes API (which is similar to reading and writing to a file from the programmers perspective) when developing the Named Pipes netlib.

Over time, new netlibs were developed, where in SQL Server 2000, this culminated in below list:

  • Shared Memory (only for local connections, obviously) 
  • Named Pipes
  • Sockets
  • RPC
  • VIA
  • SPX

There was never a netlib deveoped directly on top of NETBIOS, but indirectly through Named Pipes. Named Pipes uses NETBIOS, which available over IP, and hence is routable. In 2005, the list has shrunk to:

  • Shared Memory 
  • Named Pipes
  • Sockets
  • VIA

And I have a feeling that in the end Named Pipes will go away. I don't have any experience with VIA, but I believe that it is closer to the metal than Sockets so it might stick around for dedicated AppServer-to-SqlServer networks.

So, what does above have to do with Endpoints? Well, MS are categorizing netlibs as endpoint nowadays. This makes sense since the netlibs are a "way in" to SQL Server, as are HTTP, Service Broker and Database Mirroring endpoints.

Published Wednesday, May 28, 2008 6:37 PM by TiborKaraszi
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

unclebiguns said:

Named pipes might go away, but right now that is the only netlib through which Linq to SQL can connect to SQL Server.  So Named Pipes won't go away until Linq to SQL can connect via another netlib and MS is definitely pushing the Linq the programming model.

May 28, 2008 2:13 PM
 

TiborKaraszi said:

<<Named pipes might go away, but right now that is the only netlib through which Linq to SQL can connect to SQL Server.>>

That is not what I'm seeing. I'm using LinqPad and I have connected using both localhost and my machine name. In both cases the connections were made using LPC which is shared memory.

In general, whatever netlib is used is transaprent to the app (the app in this case is LINQ). I would be surprised if the LINQ developers were to limit LINQ in this manner - with no upside. But what do I know, perhaps NP and LPC are supported but not Sockets?

Do you have some document, URL  or so which discusses this?

May 28, 2008 2:56 PM
 

unclebiguns said:

Tibor,

Since I don't want to just pimp my little blog post about it I will provide both my blog post and the link to miscrosoft for it.

Here is my blog post:

http://wiseman-wiseguy.blogspot.com/2008/03/linq-to-sql-requirement.html

Here is the Microsoft link:

http://msdn2.microsoft.com/en-us/library/bb386929.aspx

If you are connecting to your local SQL Server it always uses Shared Memory which, I believe, uses a local version of named pipes behind the scenes (I could be wrong about this, but I think I read it somewhere).  If you disable Named Pipes on the SQL Server and try to connect from another machine using LinqPad you will not be able to connect.  I did test it, because I did not believe it either especially since Named Pipes is disabled by defualt.

May 28, 2008 4:06 PM
 

unclebiguns said:

I just did some testing and found that, if you disable Named Pipes and Shared Memory you cannot connect to a local instance of SQL Server using LinqPad.  You must have either Shared Memory or Named Pipes enabled to connect to a local SQL Server using Linq and you must have Named Pipes enabled to connect to remote SQL Server using Linq.

May 28, 2008 4:15 PM
 

TiborKaraszi said:

I was so expecting to see what you describe, but to my surprise I don't. Let me elaborate:

I first use SQL Server Configuration Manager to verify that only Shared Memory is enabled. I connect using LinqPad and execute a query successfully. I verify in SSMS Activity Monitor that the LPC netlib is used. This I take as proof that LINQ can use the Shared Memory. So apparently the MS link you posted which states that only Named Pipes can be used is not correct .

I then disable Shared Memory and also Named Pipes. The only enabled netlib now is TCP/IP. I re-start SQL Server and connect using LinqPad and successfully execute a query. I verify using SSMS Activity Monitor that the "LINQPad" application is connected using TCP/IP.

So, apparently I can connect LINQPad and execute queries using all current netlibs. This of course makes me wonder what is special with my machine and why this contradicts the MS link as well as what you are seeing. I'm using a default instance, btw, build number 9.00.3228.00.

Btw, another comment:

<<If you are connecting to your local SQL Server it always uses Shared Memory which, I believe, uses a local version of named pipes behind the scenes (I could be wrong about this, but I think I read it somewhere).>>

AFAIK, Shared Memory has nothing to do with resemblence to Named Pipes. Shared Memory is also known as "LPC" which is short for Local Procedure Call, so it probably has more resemblence to Remote Procedure Call. I don't think this matter much, though, since whatever API is used is totally abstracted by the net lib and only of interest for the net lib developers...

May 29, 2008 4:49 AM
 

jchang said:

there is slightly less overhead sending an RPC stored procedure call over VIA than TCP/IP over Ethernet, about 20K CPU-cyles lower on P4 processors. More important, the port affinity was first implemented in SQL Server 2000 for VIA only (and undocumented). Since then, SQL Server 2005 implemented and documented for both TCP and VIA. However, no one actually used VIA outside benchmarking and me, so it is essentially unsupported now. I do think Unisys does a custom driver for VIA on one of their supported FC adapters.

May 29, 2008 11:24 AM
 

TiborKaraszi said:

Cool, first time I've heard anyone using VIA... :-)

May 29, 2008 11:40 AM

Leave a Comment

(required) 
(required) 
Submit
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement