The examples for this section are in the Sample5 folder. Two projects-CustomSinkLib and SimpleObjectForSinkLib-are libraries. The client and server console projects are SinkClientExe and SinkServerExe respectively. Each of the console projects requires references to System.Runtime.Remoting.dll, SimpleObjectForSinkLib.dll, and CustomSinkLib.dll. Channel sinks are the means by which messages are passed back and forth between the client and server. Earlier in the chapter, call contexts were explored as a device to transparently pass data across the wire. A channel sink can be an alternative way to achieve the same end. But sinks are not limited to that single function. The HTTP and TCP channels, provided by .NET, have two default sinks in the sink chain-a formatter and a transport sink. The formatter converts an IMessage into a stream, while the transporter streams the data across the wire. Each does a discrete unit of work and hands the result to the next sink in the chain. The .NET Framework does not restrict the number of links in a sink chain. The sink chain can be viewed as a functional linked list, rather than a linked list of data. Depending on the problem domain, one to many sinks are plugged into a channel's chain, with each sink addressing a single task. This may include logging, security functions, encryption, or any other task that is required on the route from the transparent proxy to the remote object. To become a member of a sink chain, certain criteria must be met. All channels are divided into senders and receivers. Receivers are generally servers, while senders are clients. Channel sinks can be seen in the same light. They are connected to a channel by a sink provider, either a System.Runtime.Remoting.Channels.IClientChannelSinkProvider or an IServerChannelSinkProvider. Listing 25.28: ClientSinkProvider.cs public class ClientSinkProvider : IClientChannelSinkProvider
{
private IClientChannelSinkProvider next = null; public ClientSinkProvider()
{
} public ClientSinkProvider(IDictionary props, ICollection provider)
{
} public IClientChannelSink CreateSink(IChannelSender sender, string url, object channelData)
{
IClientChannelSink sink = null; if (next != null)
{
sink = next.CreateSink(sender, url, channelData);
} if (sink != null)
{
sink = new ClientSink(sink);
} return (sink);
} public IClientChannelSinkProvider Next
{
get
{
return (next);
} set
{
next = value;
}
}
}Deriving from the IClientChannelSinkProvider interface, described in Listing 25.28, requires implementing the CreateSink method and the Next property. The server provider code, not shown, in ServerSinkProvider.cs is the same, except for an additional method, GetChannelData(), which has a System.Runtime.Remoting.Channels.IChannelDataStore parameter. Read more: C# Corner
{
private IClientChannelSinkProvider next = null; public ClientSinkProvider()
{
} public ClientSinkProvider(IDictionary props, ICollection provider)
{
} public IClientChannelSink CreateSink(IChannelSender sender, string url, object channelData)
{
IClientChannelSink sink = null; if (next != null)
{
sink = next.CreateSink(sender, url, channelData);
} if (sink != null)
{
sink = new ClientSink(sink);
} return (sink);
} public IClientChannelSinkProvider Next
{
get
{
return (next);
} set
{
next = value;
}
}
}Deriving from the IClientChannelSinkProvider interface, described in Listing 25.28, requires implementing the CreateSink method and the Next property. The server provider code, not shown, in ServerSinkProvider.cs is the same, except for an additional method, GetChannelData(), which has a System.Runtime.Remoting.Channels.IChannelDataStore parameter. Read more: C# Corner