Передача данных по сети...

← →
Knight © (2004-11-23 16:28) [0]

Вот везде пишется, что несколько мелких пакетов могут объединяться в один и, наоборот, один большой может разбиваться на несколько мелких... типа, клиент должен сам отслеживать данные. Это не проблема если используються ServerSocket-ClientSocket... А если это UDP-бродкаст? Как, только-что зашедшему в сеть клиенту, разобраться в этой каше?

← →
Digitman © (2004-11-23 16:44) [1]

> Вот везде

где это "везде" ?
чушь не пори уже ..

> несколько мелких пакетов могут объединяться в один и, наоборот,
> один большой может разбиваться на несколько мелких

"пакет" "пакету" - рознь

> не проблема если используються ServerSocket-ClientSocket

если ведешь речь о поточном протоколе - так и говори .. а не начинай тут с абстрактных никчемных "прелюдий" ... ибо - словоблудие

> если это UDP-бродкаст?

UDP не является поточно-ориентированным протоколом, и к сабжу он не имеет отношения

> Как, только-что зашедшему в сеть клиенту, разобраться в
> этой каше?

никакой каши нет и быть не может
ибо каждое событие приема отражает факт приема одного конкретного UDP-сообщения

← →
Knight © (2004-11-23 19:03) [2]

> [1] Digitman © (23.11.04 16:44)
> где это "везде" ?
> чушь не пори уже ..

фи какие мы грубые... %(
Как везде читаю... так и пишу, чтобы разобраться... может действительно, что-то не так понял... :)

> UDP не является поточно-ориентированным протоколом, и к
> сабжу он не имеет отношения

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

← →
Verg © (2004-11-23 20:47) [3]

> фи какие мы грубые... %(
> Как везде читаю... так и пишу, чтобы разобраться... может
> действительно, что-то не так понял... :)

Да уж здесь, в "сетях", все как в Армии. :)))

А по теме... А ты о чем вообще?

> ServerSocket-ClientSocket

Открой справку, почитай, что

TServerSocket listens for requests for TCP/IP connections from other machines, and establishes connections when requests are received.
TClientSocket specifies a desired connection to a TCP/IP server, manages the connection when it is open, and terminates the connection when the application is through.

Бродкасты бывают только не в TCP.

> а вот бродкаст, как-то, остаётся за бортом.

Да, бродкастом до конца даже Windows не научалась пользоваться. Все дело в спорности самой концепции. Бродкаст - это вред для сети. Конкретный вред. Бродкаст отмниамет ресурсы у всех участников сети. Без исключения, 99% участникам этой сети ничего не давая. Это как создать TIME_CRITICAL поток и решать в нем квадратные уравнения или играть в "крестики нолики"....

← →
Knight © (2004-11-23 21:38) [4]

> [3] Verg © (23.11.04 20:47)
> Открой справку, почитай, что
>
> TServerSocket listens for requests for TCP/IP connections

Это не интересует...

> Да, бродкастом до конца даже Windows не научалась пользоваться.
> Все дело в спорности самой концепции. Бродкаст - это вред
> для сети. Конкретный вред. Бродкаст отмниамет ресурсы у

А вот бродкаст интересует... если из всей сети пакет идет 1-му проценту, то понятное дело вред... а если пакет предназначен для 99-ти, а то и 100-та процентам? имхо... проще послать всем и сразу, чем индивидуально каждому... к тому же верную инфу получит только первый, а все последующие будут получать всё более и более устаревшую...

← →
Piter © (2004-11-23 23:26) [5]

Digitman © (23.11.04 16:44) [1]
где это "везде" ?
чушь не пори уже ..

действительно, это часто говорят, имея в виду фрагментацию TCP пакетов.

Ты какой-то злой. Тебе бы отдохнуть что ли? Я сейчас оффтоплю, но хочу сказать, что отлично к тебе отношусь и уважаю. Но на самом деле - неприятно, Knight задал относительно нормальный вопрос, а ты так наехал - как будто про иконку в трее спросили...

← →
Verg © (2004-11-24 07:46) [6]

> [4] Knight © (23.11.04 21:38)

Тогда конкретизируй свой вопрос.

> к тому же верную инфу получит только первый, а все последующие
> будут получать всё более и более устаревшую...

Если вообще получит. Никто ж не гарантировал.

← →
Verg © (2004-11-24 08:21) [7]

> [5] Piter © (23.11.04 23:26)

> действительно, это часто говорят, имея в виду фрагментацию
> TCP пакетов.

Когда говорят "фрагментация", имеется ввиду IP.
У TCP нет пакетов, есть сегменты - это порции потока, которые инкапсулируются в IP. Дробя поток на сегменты любая уважающая себя реализация TCP не допускает того, чтобы размер результирующей IP датаграммы вместе с канальным уровнем превышал MTU.
Фрагментация же IP датаграмм (неважно что они в себе несут, хоть UDP, хоть TCP, хоть ICMP, да хоть что) может происходить на "изломах" MTU. На маршрутизаторах соединяющих сети с разной физикой, с разным MTU.

С другой стороны, никто не мешает мне отправить UDP датаграмму размером больше MTU. Вот тут и будет происходить IP-фрагментация (разборка). Реально в сеть полетят несколько IP датаграмм.
Способ же разборки/сборки описан в стандарте на IP.
Сборка фрагментов производится сетевым ядром и на "выходе", т.е. приложение (в сокет) получает уже полностью восстановленную (собранную) датаграмму соответсвующего протокола. Либо, не получает вовсе, если например один из фрагментов потерялся.

← →
Knight © (2004-11-24 10:04) [8]

> Verg © (24.11.04 08:21) [7]

Честно говоря, я всегда думал, что кто разобрал тот должен и собрать... т.е. данные должны передаваться тому, кто должен получить, в том же виде как было отправлено... т.е. если поломал, сделай, как було...

А потом столкнулся с сетью и начал читать... и оказалось, что всё не так. Что приложение само должно, сперва отправить размер данных, и собирать до тех пор пока объём полученных пакетов не будет раверен этому размеру... Возник следующий вопрос: а есди размер последнего пакета будет снова небольшой, то может к нему приклеиться следующая команда? И если может, то как программе, которая была загружена во время отправки данных, разобраться что где?
---
ЗЫ:

← →
Verg © (2004-11-24 10:07) [9]

> [8] Knight © (24.11.04 10:04)

Ты сначала определись - о каком протоколе идет речь. О TCP или о UDP ?

← →
Knight © (2004-11-24 10:11) [10]

ЗЫ: Многие знания преумножают скорби...

← →
Knight © (2004-11-24 10:54) [11]

> Verg © (24.11.04 10:07) [9]
> Ты сначала определись - о каком протоколе идет речь. О TCP
> или о UDP ?

Лишь бы широковещательно... а так UDP :)

← →
Verg © (2004-11-24 11:23) [12]

Широковещательно - только UDP

Для UDP так:
отправил датаграмму - может быть получил датаграмму. Если получил, то получил точно такую же, какую отправил. Никакие датаграммы не разбиваются, никакие не склеиваются. Фрагментация, о которой шла речь существует на уровне IP и для программиста сокетов является скрытым механизмом.
Последовательность доставки датаграмм, да и сама доставка не гарантирована.

Широковещательные датаграммы маршрутизаторами не передаются вовсе. Т.е. могут передаваться только в пределах одного сегмента сети.

← →
Knight © (2004-11-24 12:39) [13]

> Verg © (24.11.04 11:23) [12]
> Широковещательно - только UDP
Ну это, прозвучало ещё в вопросе... в качестве UDP-бродкаста... :)

> Для UDP так:
> отправил датаграмму - может быть получил датаграмму.
Выведется следующая.

> Если получил, то получил точно такую же, какую отправил. Никакие
> датаграммы не разбиваются, никакие не склеиваются. Фрагментация,
Ну вот и всё... что м требовалось узнать.

> Широковещательные датаграммы маршрутизаторами не передаются
> вовсе. Т.е. могут передаваться только в пределах одного
> сегмента сети.
А мне больше и не надо... %)

Спасибо. Вопрос закрыт :)

← →
Digitman © (2004-11-24 12:41) [14]

> Knight © (24.11.04 10:54) [11]
> Лишь бы широковещательно... а так UDP :)

приношу извинения за резкость в реакции на вопрос.

но в станд.справке по winsock-транспорту с использованием, например, таких message-oriented-протоколов как UDP, нет ни слова ни о каких-то там "разбиениях/склеиваниях" чего-то там.

отсюда и реакция на высказывание человека, не сподобившегося даже стандартную справку почитать перед тем как задать вопрос, но ничтоже сумняшеся заявляющего, что что-то там "везде пишется".

> Digitman © (24.11.04 12:41) [14]
> приношу извинения за резкость в реакции на вопрос.
Извинения приняты... %)

> но в станд.справке по winsock-транспорту с использованием,
> например, таких message-oriented-протоколов как UDP, нет
> ни слова ни о каких-то там "разбиениях/склеиваниях" чего-то
> там.
> отсюда и реакция на высказывание человека, не сподобившегося
> даже стандартную справку почитать перед тем как задать вопрос,

Просто статьи и примеры с толку сбили... везде фрагментация-фрагментация... вот и решил уточнить... Точно так же когда-то искал, как чат написать, что не статья, что не пример, везде Клиент-Сервер, а о том запузырить этот сервер в одноранговой сети в которой любой работает по схеме "вошёл-вышел" ни слова... так и плюнул на это дело, потому как... забадали на... :)

> забадали на

не лучший аргумент в пользу темы вопроса.

> статьи и примеры с толку сбили

начинать нужно со станд.справки.
когда что-то там неясно (согласен - не такой уж редкий случай) - бегом сюда с КОНКРЕТНЫМ вопросом, что сие в борландовской (или майкрософтовской) интерпретации для простого смертного программера означает ..

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

Verg © (24.11.04 11:23) [12]
Если получил, то получил точно такую же, какую отправил

а в UDP есть контроль целостности пакета? То есть, может UDP датаграмма дойти, но искаженной?

> То есть, может UDP датаграмма дойти, но искаженной?

Нет, не может.
Если, правда, отправляющая сторона не заплнила полое контрольной суммы в UDP датаграммы нулем. В этом случае премник не будет ее проверять, и соответственно уровень приложений может получить искаженную датаграмму.

> а в UDP есть контроль целостности пакета?

Есть - контрольная сумма пакета UDP.

> [16] Digitman © (24.11.04 16:30)
> не лучший аргумент в пользу темы вопроса.

"Забадали на"... относится к чату... Давно было... и не очень нужно... так, для общего развития смотрел. Щас столкнулся с програмингом под сеть более плотно... вот и рою по нескольким направлениям сразу, а т.к., везде где поднимается тема фрагментации, не встретил оговорки, что другим протоколам она не имеет отношения (кроме справки), решил уточнить.

ЗЫ: Приношу извинения за не очень корректный вопрос... задавал в конце рабочего дня, поэтому доводить было некогда... как сформулировалось, так и выдал в прямой эфир %)

Ешё раз всем спасибо за пояснения... дальше сам :)

Передача данных по сети... Найти похожие ветки