СКУД. Знать, что хочет заказчик

По Алкотестеру перестаньте уже, а то я напишу как все было

Ну вот все карты открыты....

И вас несколько не смущает вопрос что "карты вам путает" телемастер, т.е. - человек, фактически не имеющий ни какого касательства к по-скуд-сту?

;)

И вас несколько не смущает вопрос что "карты вам путает" телемастер, т.е. - человек, фактически не имеющий ни какого касательства к по-скуд-сту?

Шо, я-еще не-всё = знаю

Ой, как далеко не все....

этот алкотестер просто = бомба

ТРИ-УСэЦэТэ

Унификация телевизионных приёмников — использовавшаяся в радиопромышленности СССР и других стран концепция, при которой несколько телевизионных заводов выпускали телевизоры одной и той же модели по одинаковым или близким схемам, что обеспечивает совместимость узлов унифицированного телевизора, выпущенного любым из заводов, с однотипным телевизором любого другого участвующего в программе завода. Благодаря этой концепции телевизор — достаточно сложный по меркам 1960—1980 годов аппарат стал доступен практически каждой советской семье, поскольку унификация и модульность позволила наладить массовый выпуск телевизоров и существенно снизить их цену....

Ну вот опять про веселей вместе)))

А агитПлакат домофона....

Да я даже не понимаю что это...

Это дауншифтинг для пользователя = СКУД

И что мне с ним делать на предприятии?

>; Андрей, проблема в том что UDP - широковещательный пакет и чем больше отправителей - тем шире "сетевой шторм".

UDP может быть как широковещательный так и нет.

>; Ну и еще в том, что UDP пакет - не имеет квита и не требует гарантированной доставки до получателя.

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

Альтернативной было бы "не изобретать велосипед" и использовать TCP, но это более тяжело когда контроллеры должны постоянно обмениваться данными друг с другом, каждому потенциально надо поддерживать тысячу соединений с другими, что в мире встраемых решений может быть существенно. Есть и другие проблемы с TCP, в т.ч. он все равно не решит всех задач.

В целом же все эти рассуждения существуют просто для интереса. Я не думаю что надо какой-то СКУД объявлять хорошим или плохим за выбор протокола, использованный язык программирования, тип СУБД или что-то такое.

Лучше смотреть на целевые показатели. Если производитель дает прописывание новой карты в 100 контроллеров на 1 секунду, доставку событий за 1 секунду и прочее такое - то он молодец, а как он это сделал - ему типа виднее как надо.

Андрей, проблема в том что UDP - широковещательный пакет и чем больше отправителей - тем шире "сетевой шторм".

Это не так. В каждом Вашем утверждении - не так!

Дабы не отсылать в неизвестность и не вводить других участников форума в опасную самоуверенность коротко объясняю и покажу:

1. UDP - User Datagram Protocol - это протокол. Он даже не содержит IP адреса ни отправителя, ни получателя, и вызывать какие-то штормы не может в принципе (см. рисунок п.2).
2. для организации рассылки UDP другим адресатам протокол UDP "заворачивают в протокол IP. Вот тут уже появляются IP адреса и получателя, и отправителя. Именно на этом уровне уже можно говорить про широковещательные пакеты (см. рисунок п.3). Но UDP к "широковещательности" никакого отношения не имеет.
3. сетевой шторм отстоит от UDP еще дальше, чем широковещательная адресация. И порождается сетевой шторм не протоколами (любыми!), а либо активным коммуникационным оборудованием, либо неправильной организацией самой локальной сети, либо либо умышленными действиями.
4. При реальном шторме "смывает" не только протоколы UDP, но и все остальные! Сеть "ложится": не работает никакой обмен по локальной сети.

Ваше утверждение, что пакеты UDP порождают сетевой шторм с ростом количества отправителей - неправильное.

Если надо сформировать широковещательный запрос, то это делается на уровне IP пакета путем указания широковещательных адресов. Но протокол UDP тут ни при чем.

Вопрос о потерянных пакетах решается программно сторонами обмена. Тут ситуация точно как при работе RS-485: послал команду - жди получение ответа о приеме. Не принял - предпринимай какие-либо действия (пошли запрос еще раз). А связь проверяй хоть по 10 раз в секунду: обмен с конкретным девайсом не зависит от обмена с другим девайсом.

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

UDP - инструмент, а не самоцель. Каждый выбор влечет за собой набор новых задач.

О как вас зацепило-то. :))

Ну для начала к Павлу.

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

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

Ну а теперь для двух Андреев.

я точно так же не буду как и вы "отсылать в неизвестность" а потому просто как и вы процитирую чужое, просто жирно жирно подчеркну то, с чем мне приходится сталкиваться постоянно при эксплуатации потокового UDP-видео ;)

1) UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надёжности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени.

2) UDP Storm (UDP шторм) Используется в том случае, если на жертве открыто как минимум два UDP порта, каждый из которых отсылает отправителю какой-нибудь ответ. Например, порт 37 с сервером time на запрос отправляет текущую дату и время. Взломщик отправляет UDP пакет на один из портов жертвы, но в качестве отправителя указывает адрес жертвы и второй открытый UDP порт жертвы. Тогда порты начинают бесконечно отвечать друг другу, что снижает производительность. Шторм прекратится, как только один из пакетов пропадёт (например, из-за перегрузки ресурсов). Рекомендации: по возможности исключить использование сервисов, которые принимают UDP пакеты, либо отрезать их от внешней сети межсетевым экраном.

3) UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

REM Ну а выше UDP кто у нас? Правильно - 48 байт IP ;)

Ну и что имеем в итоге?

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

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

• Неупорядоченность — если два сообщения отправлены одному получателю, то порядок их достижения цели не может быть предугадан.

• Легковесность — никакого упорядочивания сообщений, никакого отслеживания соединений и т. д. Это небольшой транспортный уровень, разработанный на IP.

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

• Нет контроля перегрузок — UDP сам по себе не избегает перегрузок. Для приложений с большой пропускной способностью возможно вызвать коллапс перегрузок, если только они не реализуют меры контроля на прикладном уровне.