I’ve done a fair bit of socket programming in the past. I was part of a team that developed a distributed object architecture years before DCOM or CORBA were released, and that system used IP (predominately TCP/IP) to communicate between machines. The advantage of using IP was that it was an accepted standard and supported by many platforms, which meant that the distributed objects we were developing could exist on any platform for which we had provided the middleware.
However, all of the socket programming that I did in that job was TCP and UDP. These are just two of the possible IP protocols (numbers 6 and 17, respectively). The complete list of IP protocols is maintained by IANA (Internet Assigned Numbers Authority) at http://www.iana.org/assignments/protocol-numbers. TCP and UDP are the ones you will use most often, but if you’re on the Internet, you’re likely to be using other protocols without even realizing it.
For example, the ping utility uses ICMP (Internet Control Message Protocol, IP protocol number 1) and you can write your own ICMP based code with .NET. The Socket class is implemented by Winsock 2, which is Microsoft’s latest version of Berkeley Sockets. Winsock 2 gives a socket-based paradigm to various networks. To use it with IP, you pass AddressFamily.InterNetwork as the first parameter to the Socket constructor. The second parameter of the constructor is the socket type that you want to create, and for IP this is usually SocketType.Dgram for connectionless, unreliable UDP; and SocketType.Stream for the connection-oriented, reliable, stream-based TCP. For all other protocols, use SocketType.Raw.
You can then indicate the actual IP protocol that you want as the final parameter to the Socket constructor, and this is largely constrained by your choice for the socket type. The ProtocolType enumeration has most of the common protocols, but it does not include all of those listed by IANA or all of the ones supported by Winsock 2 (the constants with name beginning with IPPROTO_ in winsock2.h). If you want to create an ICMP packet then you use the ProtocolType.Icmp; essentially, all this does is it sets the protocol member of the IP header to 1.
Essentially, each IP protocol defines an extension to the IP header and a protocol of how particular values are handled and the responses that should be given. When you specify ProtocolType.Tcp or ProtocolType.Udp, the sockets stack does all of the work. So for TCP, it determines if more than one packet will be sent, it constructs the TCP header and appends your data, and it then sets up the connection and sends each packet with a sequence number so that the packet can be resent if it is not received by the remote socket. All you have to think about is the data that you want to send. However, if you want to use one of the other IP protocols, you have to do this work yourself: Construct the protocol header and handle the packets individually as defined by the relevant RFC. For ICMP, the header is described by RFC 792. Winsock will normally create the IP header, but if you wish, you can supply it yourself by setting the socket option SocketOptionName.HeaderIncluded using Socket.SetSocketOption.
I thought I would write some code to show this, but after some searching I discovered that a suitable example already exists. The example is part of an article by Lance Olson in the February 2001 edition of MSDN Magazine (http://msdn.microsoft.com/msdnmag/issues/01/02/netpeers) where Lance provides some code to use ICMP to send an ICMP echo packet. Note that this code was written with beta 1 of the .NET framework and, hence, there are a few changes that you have to make to make the code compile for version 1.0 or 1.1 of the framework (which I have listed in the example download).
Before I close, I ought to point out that raw sockets give you considerable power to screw up your applications and the applications on other machines if you do not follow the exact exchange of packets and data defined by a protocol. For a dissertation on the dangers, take a look at this article (http://grc.com/dos/winxp.htm) on Steve Gibson’s site. If you think that you are safe from raw sockets being used on your machine because only administrators are allowed to use raw sockets, take a look at knowledge base article Q195445 (http://support.microsoft.com/default.aspx?scid=kb;en-us;195445), which explains that even this safeguard can be turned off.
Richard Grimes speaks at conferences and writes extensively on .NET, COM, and
COM+. He is the author of Developing Applications with Visual Studio .NET
(Addison-Wesley, 2002). If you have comments about this topic, Richard can be
reached at [email protected].
