B
Boris
Is there a place to send proposals to regarding extending the framework?
In any case here is my proposal:
1) I would like to be able to get *and* set the socket in wrapper classes
TcpListener, TcpClient and NetworkStream. Only UdpClient provides get and
set accessors in the moment.
2) The Socket class should get a new constructor Socket(Socket socket) to
take over ownership of resources held by another socket.
The framework provides a non-sealed socket class that may be used to derive
new socket classes, eg:
class MySocket : Socket
{
public int i;
}
Thankfully the framework also provides some socket wrapper classes - namely
TcpListener, TcpClient, NetworkStream and UdpClient - that make life easier
for network developers. But there is a problem: You can't use a derived
socket class with them as they use the default socket class of the
framework. So when you derive from Socket you can't use your new socket
class with these wrapper classes. You have to develop your own TcpListener,
TcpClient, NetworkStream and UdpClient classes to emulate the framework's
wrapper classes because these classes miss a set accessor for the socket.
Even if the wrapper classes offered a way to change the socket they use the
Socket class by default. So if it was possible to change the socket (using a
set accessor) ownership of the resources allocated and held by the default
socket must be transferred to the new socket. Therefore the Socket class
should be extended with a new constructor Socket(Socket socket).
An updated framework would enable code like this:
class MySocket : Socket
{
public int i;
public MySocket(Socket socket) : base(socket) { }
}
class MyTcpListener : TcpListener
{
MyTcpListener(IPEndPoint localEP) : base(localEP)
{
Server = new MySocket(Server); // we change the default socket to our
socket class
((MySocket)Server).i = 1; // MyTcpListener uses a new socket class with
more functionality
}
}
What do you think?
Boris
In any case here is my proposal:
1) I would like to be able to get *and* set the socket in wrapper classes
TcpListener, TcpClient and NetworkStream. Only UdpClient provides get and
set accessors in the moment.
2) The Socket class should get a new constructor Socket(Socket socket) to
take over ownership of resources held by another socket.
The framework provides a non-sealed socket class that may be used to derive
new socket classes, eg:
class MySocket : Socket
{
public int i;
}
Thankfully the framework also provides some socket wrapper classes - namely
TcpListener, TcpClient, NetworkStream and UdpClient - that make life easier
for network developers. But there is a problem: You can't use a derived
socket class with them as they use the default socket class of the
framework. So when you derive from Socket you can't use your new socket
class with these wrapper classes. You have to develop your own TcpListener,
TcpClient, NetworkStream and UdpClient classes to emulate the framework's
wrapper classes because these classes miss a set accessor for the socket.
Even if the wrapper classes offered a way to change the socket they use the
Socket class by default. So if it was possible to change the socket (using a
set accessor) ownership of the resources allocated and held by the default
socket must be transferred to the new socket. Therefore the Socket class
should be extended with a new constructor Socket(Socket socket).
An updated framework would enable code like this:
class MySocket : Socket
{
public int i;
public MySocket(Socket socket) : base(socket) { }
}
class MyTcpListener : TcpListener
{
MyTcpListener(IPEndPoint localEP) : base(localEP)
{
Server = new MySocket(Server); // we change the default socket to our
socket class
((MySocket)Server).i = 1; // MyTcpListener uses a new socket class with
more functionality
}
}
What do you think?
Boris