I think TheCPUWizard means callback functions.
So the method (on host) 'public List<MyObject> GetMyBigCollection()' changes into a void.
Next, the big collection is returned to client using a callback function.
Printable View
I think TheCPUWizard means callback functions.
So the method (on host) 'public List<MyObject> GetMyBigCollection()' changes into a void.
Next, the big collection is returned to client using a callback function.
WCF Callback messages/functions are a type of reverse channel (which is simply where the request/response flows in the opposite direction from a normal/forward channel). Depending on the transport selected for WCF, this may be a viable option.
The important part is that there is NEVER a "big collection" or a "big message".
Consider a object collection where each instance takes 2K to represent via serialized content. Also that up to 500 of these may exist in a collection (being moved over the wire). This amounts to 1M of data [A BIG Message].
Changing the seuqence to internally use messages with a maximum of 20 objects per message would limit the message size to 40K. This means that:
1) Client requests collection [whichwill have 500 items] (request may contain parameters)
2) Server sends 13 messages \ on reverse/callback channel.
Now lets look at performance: Assume the server takes 1mS to read an object from the database and serialize it, the network takes 2mS to transmit an object, and the client takes 1mS to deserialize and process. This are artifical numbers for easy illustration.
Done as a single message the time is 500mS+1000mS+500mS = 2 SECONDS. Done using the method outlined above, the time is 500mS + 40mS + 20mS = 560mS. The "single message: takes 3.57 times as long!!!
Now lets look at memory.
a) There never needs to be more than 20 instances in server memory [96% savings]
b) There is NEVER a message string big enough to utilize the LOH on the server [risk 100% eliminated]
c) There may be no need for more than 20 instances in client memory, if the objects can be processed "on the fly" [potential 96% savings]
With just a little work, this entire pattern can be implemented using generics, and then re-used in all cases where the developer has design control over both the client and the server.
But doesn't it mean to have statefull server and to implement some kind of paging?
Not at all!!!! EVERYTHING occurs within the context of the message..
Using Psuedo code... you would originally have something like this on the server:
This becomes:Code:WCFResponse Process(WCFRequest request)
{
Collection col = GetDataFromDB();
WCFResponse retVal = ....
retVal.Data = col;
return retVal;
}
The same type of implementation is done on the client (ie All of the callbacks occur and are acknowledged within the processing period of the main message.Code:WCFResponse Process(WCFRequest request)
{
WCFLink link = new .... // Create the reverse/callback...
Collection col;
do
Collection col = GetNextGroupFromDB();
WCFREquest request = new ...
request.Data = col;
link.Process(request);
while (col.Count > 0);
WCFResponse retVal = ....
return retVal;
}
An additional benefit that I did not list: The client can cleanly cancel the transmission (and all associated processing) at any boundary...
Thanks.
Thanks for explanation CPUWizard. It will consider changing it into this reverse channel technique.
But why does the .Net framework provides this functionality to send large object, if this is not a nice way to do this (memory risk, LOH).
One additional question: Does it mean to communicate on duplex channel created using DuplexChannelFactory?