Всем привет.

На PDA передаю с сервера файл по кускам по TCP.

Куски у меня 2048 байт. 
Подумал, что если размер самого физического пакета больше, чем 2048, 
то это означает, что я не полностью задействую трафик.
Например, если размер физического пакета 32кб, а файл размером 64кб,
то теоретически его можно передать в двух пакетах, а у меня сейчас уходит на передачу такого файла 32 пакета. Т.е. 32 запроса к серверу.

А как узнать, каков размер пакета, чтобы его по возможности заполнять на 100%?

Другой пример.
Предположим мне на SD карту надо записать файл размером 2Гб.
Если предположить, что стек сам разбирается во всем, то можно 
эти 2 гига пульнуть через networkStream.Write и ждать, когда эти 2 гига прийдут.
Но, как показывает практика, 2 гига никак не влезают networkStream.

Так сколько же можно туда положить, чтобы поток не захлебнулся?
10 байт или 10 Кб или 1 Мб. Как определить допустимый или оптимальный размер?

vlsaf, при передаче информации периодически возникают ошибки. Если клиент принимает испорченный пакет, сервер отправляет его заново. Т.е. чем лучше качество канала - тем больший размер пакета можно отправлять, т.к. это увеличивает быстродействие. 
На мой взгляд, правильно определить размер пакета можно только экспериментальным путем во время выполнения программы, т.к. необходимо обладать оперативными данными о качестве канала.

Я правильно понимаю, что судить о том, испорченый пакет пришел или нет, должен я сам? Я передаю с сервера на клиента вместе с куском файла еще и контрольную сумму этого куска CRC32. Если пришедшая сумма и посчитанная сумма для принятого куска на клиенте совпадают, то пакет пришел верный и в следующий раз я могу запросить больший кусок информации? 

Или же внутренняя программа обработки TCP пакетов сама заботится об этом? 

Это сообщение отредактировал(а) vlsaf - 1.6.2009, 10:13

Если ты хочешь использовать низкоуровневые возможности и заработать кучу головной боли для получения весьма сомнительной выгоды - то да. На более высоком уровне система сама заботится о регулировке таких параметров.
Для увеличения быстродействия лучше не морочить голову с размерами пакетов и копать в сторону сжатия информации, если это позволяет специфика задачи.