> закодить такое сразу немогу


А если чуть поднапрячь извилины и поискать в гугле готовый ответ на этот вопрос ?

> sniknik ©   (27.10.10 15:59) [19]
> т.е. то что при формировании пакета на оправлении компоненты
> ставят длину данных = 0 (что совершенно правильно с точки
> зрения строк), пофиг?


В Дельфи 6(подозреваю что и в  7) TClientSocket так не делает. Кстати как и строки в дельфи (ибо строки тут первичное), по крайней мере для версий Дельфи 5 и 6. Строки в дельфи бывает довольно удобно использовать как динамический массив.... Чего кстати не было в с++ билдере, насколько помню.

> В Дельфи 6(подозреваю что и в  7) TClientSocket так не делает.
я это не придумал а взял отсюда

VFaust ©   (26.10.10 23:12) [12]
> После области TCP я наблюдаю свои данные...!!!!, но в расшифровке эти данные не значатся..., а параметр TCP.Data length = 0...!!!

т.что просто подозрений маловато.

> Строки в дельфи бывает довольно удобно использовать как динамический массив....
с этим никто и не спорит... удобно. но передавать этот динамический массив в виндовые функции через pchar очевидно не стоит. т.к.
>> P.S. Суть дело не меняет...
> а что мы знаем о строках? pchar например. и есть ли в виндовс дельфийские string...
обработка строки/расчет длинны пакета без учета (откуда ему там знать?) дельфевских "маджик" типов как будет происходить?

+ еще одно
> P.S. пробовал делать мини-Чат, всё работает...
в чем отличие того что вбивается человеком в чате от показанного здесь?

p.s. все же прямо тут, как 2 + 2 сложить...

хорошая статья, о том почему нужно знать как что то работает, а не просто использовать
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html

> Вариант   (28.10.10 07:35) [21]

Уточню - говоря о строках -я говорил об AnsiString


> sniknik ©   (28.10.10 08:07) [22]
> > В Дельфи 6(подозреваю что и в  7) TClientSocket так не
> делает.
> я это не придумал а взял отсюда



Если я правильно понял, то твое


> т.е. то что при формировании пакета на оправлении компоненты
> ставят длину данных = 0
>


ты о  


> ClientSocket нет события onRead [D7, WinXP]
>
> VFaust ©   (26.10.10 10:46)
> 2. На кнопку отсылаю ClientSocket1.Socket.SendText(#00);
>


Если так, то в ScktComp


> function TCustomWinSocket.SendText(const s: string): Integer;
>
> begin
>   Result := SendBuf(Pointer(S)^, Length(S));
> end;


где размер пакета будет определяться  Length(S)  и для случая #00 будет = 1

Если я понял неправильно, то просто я не увидел тогда, о чем был пост 19.

PS:
Возможно автор поста хотел послать не один байт 0, а два - тогда должен был сделать #0#0, а не #00 -но это мое гадание на кофейной гуще. Хотя я согласен, что в общем для посылки двоичного контента удобнее и логично использовать SendBuf.  Хоть SendText и может упростить это, но в данном случае может привести к ошибке или разночтению....

Я отсылаю один байт #00 в порт, в TCP/IP пакете прописывается длинна данных равная 1 (на скрине видно)...
Когда ко мне приходит пакет с данными #00 #00 #00 #00 #00 #00 (6 байт), в TCP/IP пакете длинна данных указана 0 (на скрине видно)...

Исходящие пакеты формирую я, к ним нареканий никаких...
Входящие пакеты формирует контроллер фирмы SIEMENS по своей, недоступной мне схеме и логике...

> VFaust ©   (28.10.10 09:56) [25]

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

> Вариант   (28.10.10 10:20) [26]

Я не прошу разбираться с ошибками контроллера, я хочу принимать пакеты с данными, если длинна указана равная 0..., ведь CommView их принимает...

> VFaust ©   (28.10.10 10:26) [27]

Если данные для тебя есть в буфере, то способ
указан в
> Сергей М. ©   (27.10.10 12:24) [17]

Моей квалификации и знаний работы в сети не хватает, что бы оценить верен этот пост(способ) или нет. Мне кажется, что это не поможет - но кажется. А когда кажется, то надо проверять, а вот как это проверить - я тебе могу подсказать - тебе надо использовать функцию setsockopt - посмотри в MSDN или в хелпе дельфи по Windows SDK (для гугла ключевые слова setsockopt, SOL_SOCKET, SO_RCVBUF).

Ну для отпетых извращенцев есть еще способ  - cотворить файрвол и в интересующих пакетах менять PSH c 0 на 1

)

> а два - тогда должен был сделать #0#0, а не #00 -но это мое гадание на кофейной гуще.
это ламеризм, а не гадание

вот


поставь не #00, а #0#0. помогло?

> Сергей М. ©   (28.10.10 11:01) [29]

Да можно извратиться и сниффером читать. Только это извращение как ты и сказал, так как порядок получения пакетов уже будет не гарантирован. Возможно все получим как надо и правильно, а может как "PSH" на душу положит. Мне кажется проблема в работе с контроллером, опять таки если в коде  для ClientSocket все верно.

> Возможно автор поста хотел послать не один байт 0, а два - тогда должен был сделать #0#0, а не #00
а, дошло... сорри
имеешь в виду, что
> передавал: #00
> должен принять: #00 #00 #00 #00 #00 #00
передавал он типа, #000000000000, а ожидает #00#00#00#00#00#00

> sniknik ©   (28.10.10 11:14) [30]


> гадание на кофейной гуще

Это относилось к тому, сколько байт хотел отправить автор поста, ибо как я писал #00 - у меня например сперва вызвал именно такую ассоциацию, что хотел два байта, но забыл #.

Ламеризм есть - это когда путают Pchar, string и pointer, функцию ShowMessage и функцию Length и отладчик. А вообще не грех например пройтись отладчиком и посмтреть результат возврата итогового SendBuf и send.

> sniknik ©   (28.10.10 11:20) [32]

Я просто хотел подчеркнуть, что SendText для отправки бинарного содержимого - это способ получить глюки, когда отправлются данные, сформированные по методу SendText(#01#0000 + там чего-то). Просто из-за того, что забыл где-то #

Люди...!!! Вы в танке, что-ли...!!!

Передаю ОДИН байт = 2 тетрады = 8 бит
SendText(#00); это тоже самое, что и SendText(#0);


> Вариант   (28.10.10 11:33) [34]

спасибо за совет, но я использую другой метод
Пример:#$03 + #$00 + #$00 + #$16 + #$11 + #$E0 + #$00 + #$00 + #$00 + #$02

> VFaust ©   (28.10.10 11:54) [35]

Да не в танке. Проблема у тебя с приемом данных ты говоришь. Просто проблема с приемом потому, что или ты где-то не так что-то делаешь и скорее всего с контроллером, в работе с ним или в твоем коде например по получению данных чрезе ClientSocket например... (Конечно я могу и ошибаться, и код нормальный и протокол работы с утройством соблюден)
Путь к тому как ты хотел читать как бы "сырые" данные тебе примерно указали ([17],[28],[29],[31]). Но это не решение проблемы, а "латание". А картинки которые ты привел - да это о чем-то говорит, что данные есть - но это одна и то неполная картинка плохого качества - по крайней мере я так увидел.  

Ты [17] пробовал ? ПОлучил отрицательный или положительный результат для решения своей проблемы?

БлагоДарю ВСЕМ...
Я понял в каком направлении мне двигаться...

> Сергей М. ©   (27.10.10 12:24) [17]
>
> ну если PSH не взведен во входящем пакете, то неудивительно
> что 6 вошедших байт висят в буфере приема и не отдаются
> приложению
>
> попробуй сразу после коннекта отключить буферизацию вх.потока
> установкой в ноль опции SO_RCVBUF клиентского гнезда


P.S. Я не говорю, что это ответ..., это направление...

> спасибо за совет, но я использую другой метод

Чем этот твой другой метод принципиально отличается от [34] использование знака плюс, так он не обязателен и принципа не меняет. Использованием хекс, тоже принципа не меняет.

> Чем этот твой другой метод принципиально отличается от [34]
> использование знака плюс, так он не обязателен и принципа
> не меняет. Использованием хекс, тоже принципа не меняет.
>

Я не знал про это...

Попробовал #$03#$00#$00#$16#$11#$E0#$00#$00#$00#$02 - работает, но это уже оффпот...