I've had a marathon weekend pumping out the code for new inet pod. This pod specifies the low level Internet and socket APIs:
IpAddress: models an IPv4 or IPv6 address and provides DNS name resolution
TcpSocket: used to manage TCP sockets
TcpListener: used to manage a TCP server socket
UdpSocket: used to manage a UDP socket
UdpPacket: used with UdpSocket to encapsulate a datagram
SocketOptions: shared options used with TcpSocket, TcpListener, and UdpSocket (removes clutter from main API classes)
I based the API more on Java than .NET - but of course made lots of changes to clean it up. We'll have to see how well it maps to the .NET APIs once we get to that point. In my humble opinion, I think the API turned out pretty darn elegant.
One big design decision I made was to define TcpSocket and UdpSocket as const classes. Although these classes aren't really immutable, nor thread safe, that seems to provide the simplest solution to give developers flexibility to develop multi-threaded IP protocols. I tried some different designs, but they all had complexity or performance trade-offs which didn't seem justified.
Future enhancements in order of priority:
Multi-cast APIs
HttpClient to manage a complete HTTP client side exchange
FtpClient
SSL
Perhaps async accept, IO
But what I've done so far is what I was shooting to get into the preview release - actually a bit more because I was going to postpone UDP - but decided to go ahead and knock it out.
brian Sat 10 Feb 2007
I've had a marathon weekend pumping out the code for new inet pod. This pod specifies the low level Internet and socket APIs:
I based the API more on Java than .NET - but of course made lots of changes to clean it up. We'll have to see how well it maps to the .NET APIs once we get to that point. In my humble opinion, I think the API turned out pretty darn elegant.
One big design decision I made was to define TcpSocket and UdpSocket as const classes. Although these classes aren't really immutable, nor thread safe, that seems to provide the simplest solution to give developers flexibility to develop multi-threaded IP protocols. I tried some different designs, but they all had complexity or performance trade-offs which didn't seem justified.
Future enhancements in order of priority:
But what I've done so far is what I was shooting to get into the preview release - actually a bit more because I was going to postpone UDP - but decided to go ahead and knock it out.