Подскажите кто знает какой размер буфера у TClientSocket TServerSocket?  
P.S. Админ исправь ошибку пожалуйста в заголовке темы.

Это сообщение отредактировал(а) Ak47black - 18.4.2007, 17:15

Какой буфер имеется ввиду?
Обычный размер 8-64кб

Для этого есть кнопошка "Report"  

Я имею ввиду когда например делаю так

То если размер посылаемого буфера большой то он приходит как несколько кусков.
По сколько байт он нарезает ?

Это сообщение отредактировал(а) Ak47black - 18.4.2007, 17:50

Это зависит от настроек системы.
В любом случае тебе вернут кол-во байт, которое было отправлено.

Добавлено через 1 минуту и 9 секунд
В качестве примера можешь взять SendStream - оно как раз крутит цикл отправки блоков, пока весь стрим не будет отправлен.

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

Спасибо 
Snowy.+

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

Ни с каким нельзя быть уверенным.
Может вообще ничего не уйти.
Как правило, до 8 килобайт уходят единым куском.
Но гарантии нет. Всякое бывает.

Добавлено через 1 минуту и 47 секунд
Склеивается всё равно всегда.
Другое дело - ты это делаешь или операционка.
Но при работе с TCP всегда нужно закладываться на поточность, а не на блочность.
То есть крутящий цикл делать придётся всегда - и на отправке и на приёме.

Добавлено через 3 минуты и 27 секунд
Другой вопрос, что ты всегда можешь написать какие-нибудь методы, которые будут крутить этот цикл сами, прозрачно для остальной логики программы.
Как например делает SendStream.
То есть ты отдал блок и забыл. А метод сам будет делать работу, пока она не будет выполнена.

У меня тут проблема, следушая клиент посылает серверу кусок файла с индефикационным номером к серверу. Сервер этот номер заранее незнает.
Как понять где начало ,а где конец, если тут была простая строка то понятно там можно-было бы чтото накрутить например <|само сообшение|>, но когда файл посылаю там может оказать в фале така-же последовательность и тогда Error.
Вариант с шифрованием например Base64 неподходит потомучтно накладен на трафик.
А с SendStream то получиться на 100%?

Добавлено через 5 минут и 57 секунд
Сначала пробовал с 8192 байт но неполучилось.
Перешол на 4380 байт работает с localhost нормально.
Боюсь что когда клиент будет находиться на удаленом компе то может нетак себя повести.

Первыми 4 байта отправляй размер данных, за ними сразу сами данные.
Н адругой стороне читай 4 байта и тяни из сокета, пока не наберёшь нужный размер.

Добавлено через 56 секунд
И пожать заодно можно перед отправкой.

Хмм.. неплохой вариант Snowy, спасиба еше раз!

можно поступить как это делают во многих системах - выделить отдельный байт как стоповый. То есть например 0 пусть будет стоповый, тогда в блоке данных можно 1 определить как расширяющий байт - идущий за ним 1 воспринимать как байт 1, либо если идущий за ним идет 2 - то определять как 0. При применении стопового бита и увеличенного буфера приема данных данные придут без изменений(по крайне мере в TCP/IP) и будут легко расшифровываться, даже если этот пакет 10 раз побит и склеен.
Главное - правильно работать с буфером после приема данных. Я обычно использую буфер на 30-50 к (более чем хватает для обычных данных) и указатель хвоста данных,чтобы при приеме очередного куска данных они шли ни куда попало,а четко на свое место.

Это сообщение отредактировал(а) AugMaster - 21.4.2007, 01:01

Стоповый бит - не очень хорошо для произвольных бинарных данных
Да и нагрузка выше.
Хотя и такой подход имеет право на жиснь, как и C++овый PChar.

в том-то и дело что стоповый байт подходит для ЛЮБЫХ бинарных данных. для примера :
с:byte;
c:=buffer[n];//читаем из буфера приема байт
c=1 - стоповый байт
c=2 - байт раширитель - дальше идет c:=buffer[n+1];if c=0 then это 1 else if c=3 then это 2
if c<>1 and c<>2 then обычные данные - преобразование не требуется
просто происходит легкая "перепаковка" данных. Конечно это грузит проц, но с другой стороны он же не гигабиты в секунду обрабатывает - у него сетевка больше сожрет проца чем алгоритм распаковки.Зато пашет безошибочно.

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