Передача 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 - и все тут ! Думай что хочешь)..

>Digitman © (17.04.03 15:32)
Ты не прав:
"Действующие лица: Stream несчастный ;) (TStream), SendText-TJvxRichEdit, UDP-TNmUDP"

> MMF

Да, пардон ... проглядел)

Ну, по кр.мере, в Д5 исходники FastNet-компоненов действительно отсутствуют, это - факт. И это должно насторожить при выборе компонентов.

Думаю, все же проблема - именно в макс.размере UDP-сообщения, несмотря на то, что сообщение об исключении никак не проявляет первопричины.

Во всяком случае есть же адрес 77f60b6f, по которому происходит отказ. Достаточно выяснить принадлежность этого адр.пр-вам, распределенным под загружаемые процессом модули. Сдается мне, что этот адрес относится к ws2_32.dll ...

>msoftware
Бросай вообще идею пересылки по NMUDP рисунков и т.д. Я в свое время пробовал дробить большие пакеты, но все это полумеры.
>Digitman
Макс. размер UPD сообщения 64Кб, интересовался этим, когда обнаружил subj.

> MMF

> Макс. размер UPD сообщения 64Кб

Да, но по-умолчанию он - далеко не 64к !)

Ладно тогда, всем спасибо за ответы. Из всего вышесказанного вытекает нижеследующее:
Будем кусками отправлять!

Передача STREAM по UDP протоколу Найти похожие ветки