Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2002.06.06;
Скачать: CL | DM;

Вниз

Сокеты   Найти похожие ветки 

 
DikobraZ   (2002-03-25 19:13) [0]

Когда посылаются данные с помощью сокетов за одно действие они склеиваются. Т.е. два сообщения объединяются в одну строку.
Как от этого избавится????


 
panov ©   (2002-03-25 19:29) [1]

вставлять разделители


 
DikobraZ   (2002-03-26 08:26) [2]

Это какие?? #10?


 
panov ©   (2002-03-26 08:37) [3]

Например, #13#10


 
Digitman ©   (2002-03-26 08:43) [4]

Даже при таком подходе ReceiveText все равно будет работать не так, как ожидается.


 
panov ©   (2002-03-26 09:56) [5]

>Digitman © (26.03.02 08:43)
А как ожидается?-)
Приходит строка, разбираем ее на подстроки, и все.
Если завершающих символов нет (разделитель), то строка сохраняется во временном буфере, ждем, пока не закончится передача строки полностью.

Или это будет выглядеть по-другому?


 
Digitman ©   (2002-03-26 10:21) [6]

пусть передатчик выполнил последовательно 2 вызова :


SendText("123");
SendText("456");


в момент возбуждения на приемнике события OnRead вх.поток будет содержать :

$61 $62 $63 $00 $64 $65 $66 $00 (8 байт)

в процессе обработки OnRead при вызове приемником метода str:= ReceiveText()

1. из буфера гнезда будет выбран весь вх.поток, доступный на данный момент, т.е. все 8 байт.

2. в переменную str будет записана строка до первого обнаруженного в потоке терминирующего символа $00, все остальное будет отброшено. Т.о., str примет значение "456", а строка, переданная вызовом SendText("456") попросту пропадет бесследно, сколько бы ни было последующих вызовов ReceiveText.

Такова в реальности логика работы ReceiveText() у компонентов, реализующих функциональность гнезд, работающих в режиме SOCK_STREAM


 
Digitman ©   (2002-03-26 10:23) [7]

Ошибка :

верно будет "Т.о., str примет значение "123""


 
yaJohn ©   (2002-03-26 12:34) [8]

2 Digitman
Т.о. можно сделать вывод, что SendText & ReceiveText работают в логике PCHAR, а не String?

2 DikobraZ
Это не баг, это фича, причем описанная в документации. Вас же не удивляет, что когда вы последовательно 2 раза пишете в файл, прочитать можно все за 1 раз.


 
DikobraZ   (2002-03-26 12:45) [9]

Я знаю, что так и должно быть. Просто мне это мешает и нужно от этого избавиться. :)


 
Digitman ©   (2002-03-26 13:02) [10]

>DikobraZ
Для гнездовой работы со строками проще всего воспользоваться UDP-протоколом (SOCK_DGRAM) вместо SOCK_STREAM

>yaJohn
Дело не в этом. Дело в том, что в теле ReceiveText() происходит неявный вызов WinsockAPI-ф-ции recv(), одним из параметров которой требуется передать размер "порции" данных, которые нужно прочитать из приемного буфера гнезда (а любой буфер гнезда, будь он передающий или приемный - это, своего рода, очередь поточного ввода/вывода данных). Так вот размер очер. строки в этой очереди заранее неизвестен, а потому считывается вся текущая очередь и далее сканируется символ за символом, начиная с "головы", до обнаружения символа-терминатора. Все, что до терминатора, записывается в результат работы ReceiveText(), все, что после - игнорируется и отбрасывается.



 
panov ©   (2002-03-26 14:18) [11]

>DikobraZ
Воспользуйся SendBuf и ReceiveBuf. В них будет работать, как надо.


 
Wizard_Ex ©   (2002-03-26 16:56) [12]

Как вариант в той же строке передавай размер:
например послал: S:="Hi!"
передается ASendText:=Length(S)+"#"+S
Потом просто используя Pos Delete Copy получаешь длину строки и собственно саму строку, а если маленько доделать, то и разбивку остатка строки точно также (если к этой S еще одно сообщение прицепилось)



Страницы: 1 вся ветка

Текущий архив: 2002.06.06;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.01 c
3-17782
Gari
2002-05-15 14:29
2002.06.06
Работа с Oracle


4-18205
_Alex_
2002-04-03 06:27
2002.06.06
чтение данных о ярлыке


6-18091
Yuraz
2002-03-25 07:20
2002.06.06
Проверка email на существование


7-18170
JonNic
2002-03-12 07:10
2002.06.06
Как определить конфиг-ю компа, какой проц, винт, память(DIMM,SIM,RIMM) ??? Которую определяет BIOS ???


7-18169
Keymaster
2002-03-12 00:05
2002.06.06
Может не совсем в тему, но очень нужно