# Data-Pull Model Versus Data-Push Model

A client of an asynchronous moniker can choose between a data-pull and data-push model for driving an asynchronous IMoniker::BindToStorage operation and receiving asynchronous notifications. In the data-pull model, the client drives the bind operation, and the moniker only provides data to the client as it is read. In other words, after the first call to IBindStatusCallback::OnDataAvailable, the moniker does not provide any data to the client unless the client has consumed all of the data that is already available.

Because data is only downloaded as it is requested, clients that choose the data-pull model must make sure to read this data in a timely manner. In the case of Internet-downloads with URL Monikers, the bind operation may fail if a client waits too long before requesting more data.

In the data-push model, the moniker drives the asynchronous bind operation and continuously notifies the client whenever new data is available. The client may choose whether or not to read the data at any point during the bind operation, but the moniker will drive the bind operation to completion regardless.

Also, you need to remember to follow the COM rules for memory allocation when using asynchronous monikers. Specifically:

- Whenever a COM interface or function call returns a buffer (string or other) to its client, the client is responsible for freeing the memory by calling CoTaskMemFree.

- Whenever a COM interface or function requires a buffer from its client, the client must allocate that buffer using CoTaskMemAlloc and the callee must free it.

Be sure to follow these rules when allocating strings or buffers that are passed to asynchronous monikers, and remember to free memory returned by asynchronous monikers. See Managing Memory Allocation and related topics for complete details.