TCP/IP vs. Named Pipes

  • Afternoon Everyone,

    I am looking for any information on comparisons between TCP/IP connections and named pipes connections. Barring that directions to kb or whitepapers that will give me ammo for an argument I am going to have. ;-)>

    I work on a project that requires secure connections both locally and remotely over citrix. I joined a few months ago. Our current app (developed in VB 6) uses named pipes to connect to the db both locally and over citrix.

    I know that tcp/ip has lower overhead. The current developer's argument is that named pipes is required to allow collection of the nt user ID and workstation name for our auditing.

    I know it can be done without named pipes. (Saw it on a previous project.)

    As always, any help is appreciated.

    Richard

    Richard L. Dawson
    Microsoft Sql Server DBA/Data Architect

    I can like a person. People are arrogant, ignorant, idiotic, irritating and mostly just plain annoying.

  • This was removed by the editor as SPAM

  • Don't have a lot to say about this subject, except for the following.

    1. Named pipes requires you to have a valid NT login on the database server. Otherwise, the network layer can't get started.

    2. TCP/IP does not have to have a valid NT login, but if you enable NT authentication on the SQL Server, you have the same result.

    So the only difference is the fact that there might be some additional user management if you're using NT authentication. You will have to add the correct database roles to the NT user or NT group that is needed. Shouldn't be a prohibitive amount of work, provided your NT security is set up correctly.

    You could have some problems if you're not using a domain, but everyone is logging on as a local user on his/her machine.

    As for the performance, you're correct in stating that named pipes incurs more overhead on the network. But on the other hand, I think they include a garantueed delivery mechanism.

    So TCP/IP is certainly better if performance is an issue. But I am not sure if the implementation in SQL Server also garantuees delivery.

  • To my knowledge named pipes do not have the same buffering capabilities as Tcp/IP. If there is network latency, named pipes can result in network timouts.


    -Dan

  • As a follow-up...here is some info from the SQL Server books Online:

    Optimizing Database Performance

    Named Pipes vs. TCP/IP Sockets

    In a fast local area network (LAN) environment, Transmission Control Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are comparable in terms of performance. However, the performance difference between the TCP/IP Sockets and Named Pipes clients becomes apparent with slower networks, such as across wide area networks (WANs) or dial-up networks. This is because of the different ways the interprocess communication (IPC) mechanisms communicate between peers.

    For named pipes, network communications are typically more interactive. A peer does not send data until another peer asks for it using a read command. A network read typically involves a series of peek named pipes messages before it begins to read the data. These can be very costly in a slow network and cause excessive network traffic, which in turn affects other network clients.

    It is also important to clarify if you are talking about local pipes or network pipes. If the server application is running locally on the computer running an instance of Microsoft® SQL Server™ 2000, the local Named Pipes protocol is an option. Local named pipes runs in kernel mode and is extremely fast.

    For TCP/IP Sockets, data transmissions are more streamlined and have less overhead. Data transmissions can also take advantage of TCP/IP Sockets performance enhancement mechanisms such as windowing, delayed acknowledgements, and so on, which can be very beneficial in a slow network. Depending on the type of applications, such performance differences can be significant.

    TCP/IP Sockets also support a backlog queue, which can provide a limited smoothing effect compared to named pipes that may lead to pipe busy errors when you are attempting to connect to SQL Server.

    In general, sockets are preferred in a slow LAN, WAN, or dial-up network, whereas named pipes can be a better choice when network speed is not the issue, as it offers more functionality, ease of use, and configuration options.


    -Dan

  • I've just stumbled across this as I've had to start looking into named pipes and TCP/IP. All of our SQL data is delivered to IIS, either via the intranet, through firewalls, down cable or across Dial-Up.

    We have been experiencing problems with speed from remote clients, even those using dedicated lines, and I started wondering whether the named pipe ODBC connections that the network team setup may have been the fault.

    We have already had one dial-up client that I had to switch to TCP/IP and named pipes were lagging out, so I'm about to instigate a server wide switch. Whilst our internal network is not a problem, or remote clients are the main reason for the intranet/internet applications and speed if required over functionality, especially as there are no dedicated apps trying to connect as well from local machines.

    Am I making the right move? We'll find out soon enough.


    ---------------------------------------
    It is by caffeine alone I set my mind in motion.
    It is by the Beans of Java that thoughts acquire speed,
    the hands acquire shaking, the shaking becomes a warning.
    It is by caffeine alone I set my mind in motion.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply