--null--.... а также проверку насчет целостности информации и отсутствия искажений....

А вот с этого места поподробнее...
какую такую целостность ?
какое такое отсутствие искажений ?

Т.е. я правильно Вас понимаю, что на CRC в пакете UDP протокол кладёт большой и толстый (если он не нул) ?

может документацию почитаем, вместо того, что бы сказки рассказывать ?


с уважением
(круглый)

--null--в протоколе UDP не обязательно использование контрольных сумм
...и второе- не гарантируется порядок поступления пакетов. Впрочем, для данной ситуации порядок не важен - сообщение видимо короткое
вот и все сказки а точнее RTFM :-)

1) не обязательное - это НЕ значит, что НЕЛЬЗЯ !
2) а порядок пакетов разве влияет на их ЦЕЛОСТНОСТь ? :)

а по поводу отличий UDP от TCP того же, лишь в том, что UDP НЕ ГАРАНТИРУЕТ ДОСТАВКУ.

(круглый)

miksoftа по поводу отличий UDP от TCP того же, лишь в том, что UDP НЕ ГАРАНТИРУЕТ ДОСТАВКУ.
увы... совсем не лишь !
описание UDP занимает меньше трех страниц, TCP - 85, не считая оглавления.[/quot]

в очередь, только...в очередь..
А теперь правильный вопрос...

ВЫШЕ СМОТРИМ...видим...извиняемси...
речь шла О ПАКЕТЕ !!! одном заметьте ! ШИРОКОВЕЩАТЕЛЬНОМ !
и обьясните мне дураку... Как на ЛИКВИДНОСТЬ в ШИРОВЕЩАТЕЛЬНОМ пакете влияет ОЧЕРЁДНОСТь ?

ну и ?
давайте лучше быстренько открывайте доки по протоколам и освежайте память...а то енто ни в какие ворота млин...


для тех кто в танке, и верит в сказки....
1) UDP не гарантирует доставку пакетов. Соответственно данные могут приходить упорядоченно, могут не упорядоченно, могут не приходить... УЕС ? Или опять бум спорить ?
2) На один отдельно взятый пакет - очерёдность НУ НИКАКИМ БОКОМ НЕ распространяеться... УЕС ? Или бум спорить ?
3) Если CRC заполнена в UDP - она проверяется (должна проверяться по спецификации). УЕС ? Или бум спорить ?

4) Странные у Вас подходы - о качестве материала судить по страницам... Вот по кол-ву страниц - не скажу, в своё время изучал материал, а не кол-во этих страниц :)


с уважением
(круглый)

--null--....Соответственно, используя udp было бы неразумно доверять операционке в этом вопросе. Тем более, повторяю - мы не знаем, что за ось....

возможно Вы правы...с точки зрения факта заполнения. Но тоды мы не можем доверять и другому функционалу операционок...например целостности данных считанных с диска... но это уже другая тема...

(круглый)

--null--почему? Целостность считанных данных как раз гарантируется. Как и целостность данных, приходящих по IP.
Скажем, контроллеры SCSI учитывают четность, контрольную сумму и время ожидания. И при проблемах - способны повторить чтение и снизить скорость передачи. Во всяком случае так в описаниях SCSI пртокола.

т.к. протокольный уровень - енто уровень ядра(драйвера, сама ось и прочее), и данный уровень ведёт себя не по закону(протокол) - то мона ожидать урезание (искажение) функционала и в другом месте данного ядра. Логично ? (как говорит одна девочка). Чтение с диска не ограничивается применяемым железом и протоколом нижнего уровня (уровня железа). Над ним ышо много всяких телодвижений. Например ось может положить на такую функциональность как чтение-после-записи. И всё. Вроде как быстро - меньше телодвижений. Вроде как работает.... но до первого сбоя...


лано...возвращаясь к баранам...
если идёт речь о серваке приложения - то существует такая вещь как регистрация/разрегистрация. Правда тут нуна оговориться, что это зависит от политики самого сервака. Но предположим, что такие фазы существуют. Тогда нам никто не мешает известить клиентов об изменениях оперируя учётными записями. Речь мона вести и об оптимизации данного функционала.

Что использовать на нижнем уровне - думаю тут предпочтение у каждого своё.

Говорить о БД, как о средстве синхронизации в данной схеме - мягко говоря странно. Первичен сервак приложения, а уж потом БД. И завязываться на реализацию более нижнего уровня (БД), на мой взгляд - сужение потенциальных возможностей. Нафига тоды вооще городить сервак приложения ?

с уважением
(круглый)