Следующее относится ко всей .NET Framework, поскольку ваш вопрос помечен как ASP.NET. (В Silverlight все может быть иначе.)
Краткий ответ: это сложно, поведение зависит от различных факторов, в том числе от характеристик производительности сети, поэтому оно несовместимо, и вы не можете легко его контролировать.
Длинный ответ:
Событие обычно вызывается каждый раз, когда базовый поток, предоставленный WebResponse
, вызывает обратный вызов завершения для операции BeginRead
, которую WebClient
использует для выполнения асинхронных загрузок.
Похоже, что WebClient
, как правило, будет пытаться прочитать данные кусками по 64 КБ. Однако потоки не обязаны возвращать столько данных, сколько запрашиваемый вызываемый - вполне возможно, что вызов BeginRead
, который запрашивает 64k, будет возвращать меньше. Фактически, это довольно распространено для потоков, которые читают данные из сети - они, скорее всего, вернут меньшее количество данных вскоре после того, как они станут доступны, вместо того, чтобы ждать, пока все 64 КБ не поступят.
Таким образом, точный ответ зависит от рассматриваемого потока, а также может в некоторой степени зависеть от характера и производительности сетевого соединения.
WebClient
использует WebRequest.Create
для получения реализации запроса / ответа, которая в конечном итоге предоставит поток, и это расширяемый механизм - .NET имеет 5 встроенных реализаций WebRequest
и предлагает механизм расширяемости, который позволяет Вы регистрируете дополнительные обработчики. И именно конкретная реализация WebRequest
определяет природу потока.
Таким образом, частота, с которой вы получаете события прогресса, полностью зависит от типа загрузки, которую вы делаете - вы можете получить разные результаты в зависимости от того, какой это тип URL. (Например, http против ftp против файла или что-то еще.)
Я рискну предположить, что вы используете HTTP.
Даже тогда это довольно сложно - HttpWebResponse
не всегда использует один и тот же вид потока. Например, иногда он может возвращать поток, полученный из MemoryStream
, иногда он имеет тип ConnectStream
...
Таким образом, вы не можете с уверенностью сказать, какой размер фрагментов может вернуть базовый поток, потому что вы даже не можете быть уверены, какой тип потока вы получите.
Что касается того, можете ли вы управлять им, то единственным способом, которым вы могли бы, было бы предоставить пользовательскую реализацию WebRequest
для пользовательской схемы URL. Но, честно говоря, возможно, проще просто написать код, который решает, делать ли что-либо с каким-либо конкретным событием, а не пытаться изменить частоту событий.