Sap протокол что это
SAP stands for Session Announcement Protocol. It is defined in RFC 2974.
It uses multicast to announce streams efficiently on a Local Area Network or on the MBONE: any computer on the network can receive announces from all others without any manual configuration.
SAP conveys SDP’s to describe streams parameters. This can include an RTSP control URL to use for setting up the stream, or a multicast group address to subscribe to. The SDP also includes port numbers and audio/video codecs parameters, and a stream name, etc.
This technique allows a lot of server to emit streams (often multicasted) and announce them on the network. Clients on the network can then listen for these announces.
VLC can do this with the «SAP» service discovery plugin.
You then get a listing of all these streams and can simply tune into the stream of your choice.
Because SAP uses multicast (as do UPnP and Apple Bonjour), it can normally only operate on a Local area network.
Unless your computer is connected to the MBONE, you cannot use SAP to advertise your streams onto the Internet, nor can you receive streams from other places.
SAP – Session Announcement Protocol
Session Announcement Protocol as an experimental protocol designed for the purpose of multicasting a session’s information. IETF issued it as RFC 2974. SDP (Session Description Protocol) is being used by SAP as real-time transport protocol’s session depiction arrangement. With SAP use, correspondent can transmit SDP descriptions from time to time to an acknowledged multicast address and also to port.
The announcement interval can be considerately altered in a way that each and everyone SAP announcement within a multiple transmission deliverance scope may use 4000 bits/second. Announcements will by design terminate after every 10 times (announcement interval) but greater value for termination can be an hour.
Cache Timeout for SAP
A command SAP cache-timeout can be used to restrict how long a SAP cache entry should be hanged as active within cache by means of the global configuration mode.
Ways to Authenticate, Encrypt and Compress
SAP offered methods for authentication and encryption of announcements but encryption use is not always recommended. Anyway, process of authentication is necessary to prevent the not permitted changes and also to stop DoS (denial-of-service attack) attacks. But this way of authentication is not obligatory. But anyone, from two suggested schemes for authentication, can use anyone. These schemes are named as Pretty Good Privacy (specified within RFC 2440) and Cryptographic Message Syntax (specified within RFC 5652)
SAP (v2) as an announcement protocol can be utilized by the session directory clients. But SAP announcer need to multicast the announcement packets periodically to a renowned multicast port and address. The announcement can be multicast (sending to cluster of hosts) with the identical scope. Following are some information relating to SAP (for IPv4) data packet format.
The SAP packet (for IPv4) is consisted on version type, MT (message type field that is pointed to whether packet is broadcasting a session, or canceling an announcement), E (payload encrypted of one bit that pointed out, in any case payload should be encrypted), C (payload compressed of one bit that pointed out, in any case payload should be compressed). Auth length (words relating authentication statistics where word = 32 bits but data can be padded if it is required). Message id hash field of packet is used as a unique identifier intended for the message.
The grouping of message ID hash field and original source field can be made-up to proffer an exclusive announcement ID so to recognize a particular version of current specific session. This is practical approach for both caching and ignoring packets in case of decryption, etc. SAP announcement can be validated by incorporating a payload’s digital signature in the field “optional authentication header”. SAP comprises method can make sure the reliability of session announcement by means of message ID hash plus encrypting announcement.
In short, SAP protocol can be use to publicize multicast conferencing session over the internet. But a conference needs to be announced by sporadically multicasting the packet with UDP announcement towards a multicast address (assigned to system) and to port. That is because this specific protocol SAP is intended for multicasting for example, well for conference calls, but not for IP telephone calls between two.
Протокол sap
Системы NetWare используют Service Advertising Protocol (SAP, протокол извещения об услугах) для составления и поддержания списка файловых серверов, серверов печати, серверов шлюзов и многопротокольных маршрутизаторов, расположенных в сети. Серверы при помощи SAP информируют другие системы в сети о своем присутствии. Клиент NetWare, прежде чем отправлять запросы к серверам, должен узнать об их существовании из сообщений SAP. Каждый сервер посылает широковещательные сообщения SAP с интервалом по умолчанию в 60 секунд. Эти сообщения содержат имя сервера, его адрес и описание услуг, предоставляемых им. Другие системы в сети при получении сообщения SAP создают для каждого сервера, перечисленного в сообщении, временную запись в своей базе данных ресурсов сети (bindery) или NDS, надлежащим образом сохраняя сопровождающую информацию.
Вдобавок к этой автоматически предоставляемой широковещательной рекламе, серверы также могут вырабатывать собственные запросы SAP для того, чтобы затребовать информацию от определенного сервера. NetWare использует этот тип транзакции SAP для реализации защиты от копирования, которая предотвращает возможность работы в одной сети двух серверов с одним и тем же номером лицензии, а клиенты применяют его для выявления ближайших к ним серверов. Для данного типа транзакций предусмотрены отдельные форматы пакетов: запроса ближайшего сервера (Nearest Server Request) и ответа ближайшего сервера (Nearest Server Reply). Обычные широковещательные сообщения SAP, содержащие информацию о сервере, задействуют тип пакета Standard Server Reply (ответ обычного сервера). (Тип сообщения Standard Server Request (запрос обычного сервера) не используется.)
Запросы и ответы SAP применяют различные форматы пакетов, но все сообщения SAP переносятся стандартными дейтаграммами IPX со значением в поле типа пакета (Packet Туре), равным 4, и номером сокета назначения (Destination Socket) 0452.
Кадр запроса SAP
Сообщения запроса SAP используются только тогда, когда система запрашивает у сервера информацию SAP, например, когда клиентская система определяет положение ближайшего сервера. Сообщение передается как широковещательное, и предполагается, что все серверы, принявшие его, должны ответить. Сообщение запроса состоит только из двух полей.
Тип пакета (Packet Туре), 2 байта. Указывает на функцию сообщения при помощи следующих шестнадцатеричных значений:
•1 — запрос обычного сервера (не используется);
•3 — запрос ближайшего сервера.
Тип сервера (Server Туре), 2 байта. Определяет тип услуг, требуемых от сервера.
Кадр ответа SAP
Формат ответа SAP для широковещательных сообщений и ответов на сообщения запроса ближайшего сервера один и тот же. Разница между ними заключается в том, что ответ ближайшего сервера содержит информацию только о нем самом, а ответ обычного сервера может включать данные о нескольких серверах (максимум о семи). В последнем случае вся последовательность полей, начиная с поля типа сервера и до поля количества промежуточных сетей, будет повторена до семи раз.
Так как сообщения ответа обычного сервера передаются как широковещательные, то их распространение ограничено пределами локального сегмента сети. Тем не менее, за счет предоставления в совместное пользование информации о себе, а также и обо всех остальных серверах локального сегмента, каждый сервер в сети имеет возможность составить полный список всех других серверов.
Тип пакета (Packet Туре), 2 байта. Указывает на функцию сообщения при помощи следующих шестнадцатеричных значений:
•2 — ответ стандартного сервера (Standard Server Reply);
•3 — ответ ближайшего сервера (Nearest Server Reply).
Тип сервера (Server Type), 2 байта. Определяет тип услуг, предоставляемых сервером, возможны те же значения, что и в формате сообщения запроса.
Имя сервера (Server Name), 48 байтов. Содержит имя сервера.
Адрес сети (Network Address), 4 байта. Указывает адрес сети, в которой расположен сервер.
Адрес узла (Node Address), 6 байтов. Содержит адрес сетевого интерфейса сервера.
Сокет (Socket), 2 байта. Объявляет сокет, который сервер использует для приема запросов на свои услуги.
Промежуточная сеть (Intermediate Network), 2 байта. Фиксирует количество транзитов (то есть маршрутизаторов или сетевых адресов) между сервером и системой назначения.
Проблемы SAP
На протяжении всей своей истории существования наиболее часто NetWare критикуют за ее тесную связь с протоколом SAP и огромное количество широковещательного трафика, который этот протокол создает в сети. NDS сократила объем вырабатываемого трафика за счет того, что информация о серверах хранится в базе данных службы каталогов. В случае нормального выполнения процессов репликации NDS данные SAP реплицируются через сеть посредством однонаправленной передачи сообщений между серверами, что является более предпочтительным вариантом, нежели чем широковещание. NetWare 5 еще дальше продвинулась в решении этой проблемы, включив поддержку протокола обнаружения работающих служб (SLP, Service Location Protocol), позволяющего автоматически настраивать сетевые ресурсы и стандартизированного проблемной группой проектирования сети Интернет (IETF, Internet Engineering Task Force).
Sap протокол что это
The Session Announcement Protocol (SAP) must be one of the simplest protocols around. To announce a multicast session, the session creator merely multicasts packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place. People that wish to know which sessions are going to be active simply listen to the same well-known multicast group, and receive those announcement packets. Of course, the protocol gets a little more complex when we take security and caching into account, but basically that’s it.
The SAP packet format (for IPv4) is shown in figure 6.2. The Message Type (MT) field indicates whether this packet announces a session, or deletes an announcement. One bit (E) indicates whether or not the payload is encrypted and one bit (C) indicates whether or not the payload is compressed. The combination of message ID hash and original source is supposed to provide a unique announcement ID that can be used to identify this particular version of this particular session. This is useful for caching or for ignoring packets that we previously failed to decrypt, but as this announcement ID is not guaranteed to be unique, care must be taken to also check the packet length and periodically check the packet contents themselves.
SAP announcements can be authenticated by including a digital signature of the payload in the optional authentication header . Both PGP and PKCS#7 based digital signatures are currently supported in the SAP protocol, although currently not many announcements are authenticated. As multicast-based sessions become more popular and people attempt to subvert them, this will no-doubt change.
SAP announcements can also be encrypted. However, this does not mean that the standard way to have small private wide-area conferences will be to announce them with encrypted SAP — the Session Initiation Protocol is a more appropriate mechanism for such conferences. The main uses for encrypted SAP announcements would appear to be in intranet environments where the SAP announcement bother few additional people, or for very large sessions where members are charged to participate. In the latter case, it would probably be a good idea to provide an additional level of access control beyond SAP encryption because it is easy for one misbehaving participant to leak a SAP key to other potential participant unless the keys are embedded in hardware as they are with satellite television smart cards.
The announcement rate for SAP is quite low, with typically several minutes between repeated announcements of the same session. Thus a user starting a SAP receiver will have to wait for a few minutes before seeing all the sessions. This is normally solved by caching — either by running a SAP receiver in the background all the time to keep the cache up-to-date, or by going to a local SAP proxy on startup and requesting a cache download.
It should be clear that although SAP will scale to any number of receivers, it will not scale to huge numbers of sessions. It is currently an IETF Experimental Standard, which reflects this belief that we will eventually need to replace it with something different. In the meantime though, it is a great way to bootstrap the use of IP multicast, and with appropriate caching, SAP will be OK with up to a few thousand sessions advertised.
SAP should be used for sessions of some public interest where the participants are not known in advance. If you know who you want in your session, a better mechanism is to explicitly invite them using SIP.