Форум: "Сети";
Текущий архив: 2003.06.19;
Скачать: [xml.tar.bz2];
ВнизПередача STREAM по UDP протоколу Найти похожие ветки
← →
msoftware (2003-04-17 11:14) [0]Господа программисты, помогите пожалуйста. Какая-то ошибка преследует меня целую неделю. Если вы мне не поможете мой проект провалится :(((. А дело собственно такое: Строю я программку-чат, с возможностью передачи, смайлов, всевозможных рисунков, форматированного текста и др.. OLE. Компонент который я использую для подготовки сообщений это TJvxRichEdit из библиотеки RxLib.
Действующие лица: Stream несчастный ;) (TStream), SendText-TJvxRichEdit, UDP-TNmUDP
Кусок злощастного кода отправки данных:
var Stream: TMemoryStream;
begin
try
Stream:=TMemoryStream.Create;
{Записываем в поток содержимое отправляемой строки}
eSText.Lines.SaveToStream(Stream);
{ОТПРАВЛЯЕМ...}
udp.SendStream(Stream);
finally
Stream.Free;
end;
Процесс приема данных описывать небуду, т.к. ошибка возникает только здесь.
Ошибка такая:
+-------------------------------------------------------------------------------------+
| Faulted with message: "access violation at 0x77f60b6f: write of address 0x00040fec".| | Process stoped. |
+-------------------------------------------------------------------------------------+
Она возникает не всегда! Если например более одного рисунка в отправляемом сообщении, то ошибка обязательно происходит. Иногда происходит сразу при передачи одного рисунка, некоторые рисунки она передает, некоторые нет, возникает ошибка.
Вобщем может кто знает, я считаю что возможно в компоненте этой какая то недоработка.
← →
Msoftware (2003-04-17 12:55) [1]Help me please!!!
← →
Zelius (2003-04-17 14:03) [2]Попробуй после eSText.Lines.SaveToStream(Stream); вставить Stream.Position := 0;
← →
ErikIvanov (2003-04-17 14:21) [3]Можно попробовать использовать Indy. Запиховать Stream в буфер а затем отправлять.
← →
Digitman (2003-04-17 14:22) [4]размер UDP-пакета ограничен. Скорей всего, это и приводит к отказу такого рода (размер потока превышает макс.размер пакета)
Прочитай значение размера UDP-сообщения, установленного по-умолчанию. Измени его, если необходимо.
см. Get/SetSockOpt, опции so_sndbuf, so_rcvbuf
либо "руби" содержимое потока на куски, равные тек.макс.размеру UDP-сообщения и передавай/принимай его в несколько приемов
← →
MMF (2003-04-17 14:36) [5]Пересылай не SendStream, а SendBuffer. для первого метода размер ограничен 8096 байт.
← →
Digitman (2003-04-17 14:55) [6]
> MMF
> для первого метода размер ограничен 8096 байт
что за чушь ? где, что и чем ограничено ? и - что за цифирь такая - 8096 ? может таки все же 8192 ? или 4096 ?
← →
MMF (2003-04-17 15:01) [7]>Digitman © (17.04.03 14:55)
Экпериментальные данные - варьировал размер потока. Степень двойки ни при чем. Просто это последняя длина потока, с которым не работала компонента, и на пробу которой у меня хватило сил.
← →
Digitman (2003-04-17 15:09) [8]
> MMF
ну а причем здесь SendBuf() ? чем по-твоему сей метод принципиально отличается от SendStream() ? по-моему - ничем.
первый метод в своем теле вызывает второй как базовый
← →
MMF (2003-04-17 15:27) [9]>Digitman © (17.04.03 15:09)
1) "первый метод в своем теле вызывает второй как базовый" - исходников компоненты не видел, не знаю.
2) я просто высказал свое скромное ИМХО, правда забыл указать, что это только ИМХО, основываясь всего-лишь на личный опыт общения с этой компонентой. Однако, когда я столкнулся с той же проблемой, что и автор темы, то в поисковике нашел, что не я единственный споткнулся об SendStream, сейчас попробую найти ссылки.
← →
Digitman (2003-04-17 15:32) [10]
> исходников компоненты не видел, не знаю.
да и компонент-то - непонятно какого класса) ... UDP - и все тут ! Думай что хочешь)..
← →
MMF (2003-04-17 15:38) [11]>Digitman © (17.04.03 15:32)
Ты не прав:
"Действующие лица: Stream несчастный ;) (TStream), SendText-TJvxRichEdit, UDP-TNmUDP"
← →
Digitman (2003-04-17 15:54) [12]
> MMF
Да, пардон ... проглядел)
Ну, по кр.мере, в Д5 исходники FastNet-компоненов действительно отсутствуют, это - факт. И это должно насторожить при выборе компонентов.
Думаю, все же проблема - именно в макс.размере UDP-сообщения, несмотря на то, что сообщение об исключении никак не проявляет первопричины.
Во всяком случае есть же адрес 77f60b6f, по которому происходит отказ. Достаточно выяснить принадлежность этого адр.пр-вам, распределенным под загружаемые процессом модули. Сдается мне, что этот адрес относится к ws2_32.dll ...
← →
MMF (2003-04-17 16:06) [13]>msoftware
Бросай вообще идею пересылки по NMUDP рисунков и т.д. Я в свое время пробовал дробить большие пакеты, но все это полумеры.
>Digitman
Макс. размер UPD сообщения 64Кб, интересовался этим, когда обнаружил subj.
← →
Digitman (2003-04-17 17:10) [14]
> MMF
> Макс. размер UPD сообщения 64Кб
Да, но по-умолчанию он - далеко не 64к !)
← →
Msoftware (2003-04-18 10:07) [15]Ладно тогда, всем спасибо за ответы. Из всего вышесказанного вытекает нижеследующее:
Будем кусками отправлять!
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2003.06.19;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.007 c