Не подскажете как можно определить текущее количество байт ( или время ), 
переданных на сервер.



Как это сделать параллельно с записью в поток (writeStream.Write).

Можно ли на этой основе сделать ProgressBar, 
зная размер передаваемых данных (data) и текущее число байт в единицу времени.

По твоему коду - никак. Можно разбить data на несколько, скажем 10 массивов байтов, передавать их по одному. 
По значению свойства NetworkStream.CanWrite передавать следующий массив и инкременировать счетчик или управлять прогресс-баром (когда CanWrite=true, значит массив (10% всех данных) передан и можно передавать следующий)

Спасибо за ответ tol05

Мне также посоветовали  делать запись в асинхронном режиме. 

После срабатывания установленного  callback'a  --- порция данных ушла ---  двигается прогресс.

Посмотрел MSDN:


Есть ли в этом смысл или нет ???

Это сообщение отредактировал(а) Modul - 2.5.2007, 23:30

Да, можно и так. Но ведь смысл не меняется. А смысл в том, чтобы передавать данные порциями и в том, что передача закрыта от тебя. А что делать после передачи пакета - вызывать callback или инкременировать счетчик - дело вкуса, не так ли? 
Что касается производительности - то ты можешь код просто запихнуть в отдельный поток (создашь собственный асинхронный режим  ), асинхронные методы так и делают.

tol05, насколько мне известно, асинхронные методы работы со stream'ами используют порты завершения ввода-вывода (I/O completion ports), и потоки из пула для организации ожидания и последующего callback'а. 

Да, это так. Ну и что?  
Все равно это поток. А если речь идет о том, что я на свой поток производительность зря расходую, так ведь и пул-то создается по умолчанию с ограниченным кол-вом потоков, так что не факт, что при асинхронном чтении/записи он не кинется поток создавать.

А я могу своим потоком сам управлять, абортнуть его, например али приоритет поменять.

Так что я думаю, это не принципиально. Хотя и накладно несколько, согласен.
Вопрос темы в другом - пакеты данных.   

Проблема в том, что в синхронном режиме у тебя поток не спит, а занят отправкой данных. Зачем его вообще запускать самому? Вызвал BeginWrite, и сиди себе спокойно   Причем поток из пула находится в состоянии ожидания, пока ось не сообщит в I/O completion порт, что данные зачитаны/записаны   Код будет понятнее.

Ну да не суть.