Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
invm
Mike_za
Как на 1м этапе можно получить второй хенд , не используя системную вьюху с endpoints?
Какой второй? Нет никаких вторых.
Хендл берется из полученного сообщения - столбец conversation_handle при чтении из очереди инструкцией receive.


автор
A conversation consists from two endpoints, initiator and target, each with its own handle. The initiator endpoint is the one returned by the BEGIN DIALOG. The target endpoint is created by the first message arriving at the target service. Looking into sys.conversation_endpoints will show these two endpoints. The two endpoints belongig to the same conversation will have same value for conversation_id. BOL describes this here: http://msdn2.microsoft.com/en-us/library/ms166083.aspx

In your example, you are sending on the initiator's handle and trying to receive on the same handle. The initiator has no messages to availabe to be received, the message on the queue belongs to the target (since it was sent by initiator to target). You would have to receive this message (using the target's handle) and send back a reply to the initiator. Then the initiator would have a message available to be received.


Собственно второй - это хендл диалога со стороны target-a.
13 апр 16, 01:15    [19050092]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Собственно линк.
Немного проясняет.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3b97ab0e-0939-4597-8c6f-c1147d60bb43/receiving-from-queue-by-conversationhandle?forum=sqlservicebroker
13 апр 16, 02:56    [19050148]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
Кто-нибудь может обьяснить чем нАтификация отличается от нОтификации ?
Это имеет какое-то отношение к NAT, или что вообще здесь происходит?
13 апр 16, 10:55    [19050962]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
ART-CODE
Кто-нибудь может обьяснить чем нАтификация отличается от нОтификации ?
Это имеет какое-то отношение к NAT, или что вообще здесь происходит?


важно то, что общая часть стабильна, при этом fick(de) == fuck (en)
13 апр 16, 11:08    [19051023]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
ART-CODE,

Здесь происходит "проектирование - сборка - разборка - сдача на металолом" велосипеда.
13 апр 16, 11:08    [19051027]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
Mike_za,
А вот, кстати, о велосипедах:
у меня свой велосипед на этот случай остался, еще с тех пор, когда я на Express Edition работал
- там сервис-брокера, вроде как не было.
Написал расширенную хранимую процедуру, которую вызывал из триггера или из процедур, когда надо уведомить.
Процедура устанавливала сокетное соединение с получателем и передавала данные.
Для приема сообщения клиент-получатель при старте поднимает серверный сокет и все время ждет входящее соединение от сервера.
13 апр 16, 11:22    [19051081]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
Ну там получатель один предполагался - другой сервер.
Если много получателей, то лучше в обратку - серверный сокет на стороне сервера, а клиенты при старте к нему
подключаются и все время находятся в состоянии установленного соединения и ждут входящие данные.
Типа чата или пуша.

Ну, это все было про велосипедостроение.
13 апр 16, 11:25    [19051098]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Glory
Member

Откуда:
Сообщений: 104751
ART-CODE
Кто-нибудь может обьяснить чем нАтификация отличается от нОтификации ?

Отличается так же, как "скедул" от "шедул"
13 апр 16, 11:47    [19051257]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
ART-CODE
Mike_za,
А вот, кстати, о велосипедах:
у меня свой велосипед на этот случай остался, еще с тех пор, когда я на Express Edition работал
- там сервис-брокера, вроде как не было.

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


был
13 апр 16, 11:59    [19051352]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
Ролг Хупин,
был

Ну, если был, значит по какой-то другой причине стал велосипедить.
Дело было в 2005 году. Подробности уже теряются в тумане времен.
13 апр 16, 12:23    [19051484]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
ART-CODE
Member

Откуда:
Сообщений: 1095
Уточнение: год 2007/2008 а сервер 2005 - для буквоедов :)
А то опять скажут не было такого.
13 апр 16, 12:37    [19051545]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
ART-CODE
Mike_za,
А вот, кстати, о велосипедах:
у меня свой велосипед на этот случай остался, еще с тех пор, когда я на Express Edition работал
- там сервис-брокера, вроде как не было.
Написал расширенную хранимую процедуру, которую вызывал из триггера или из процедур, когда надо уведомить.
Процедура устанавливала сокетное соединение с получателем и передавала данные.
Для приема сообщения клиент-получатель при старте поднимает серверный сокет и все время ждет входящее соединение от сервера.


у нас тоже 2005. причем включая Experss и LocalDB. тут есть брокер, как я понимаю.

ваша реализация знакома... но так совсем не хочется делать))
13 апр 16, 12:48    [19051605]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Mike_za
Мне для чтения из очереди инструкцией ресиве хотелось указать в фильтре хендл, котопый я не могу получить
Столбец очереди conversation_handle содержит хендл противоположной стороны диалога, т.е. адресата сообщения, а не отправителя.
Поэтому для фильтрации в receive нужно знать свой локальный хендл, хендл партнера не нужен.
13 апр 16, 12:49    [19051614]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
invm
Mike_za
Мне для чтения из очереди инструкцией ресиве хотелось указать в фильтре хендл, котопый я не могу получить
Столбец очереди conversation_handle содержит хендл противоположной стороны диалога, т.е. адресата сообщения, а не отправителя.
Поэтому для фильтрации в receive нужно знать свой локальный хендл, хендл партнера не нужен.


перед получением в ресев, надо как-то отправить сообщение со второй стороны (авто активации то нет). а что бы прикинуться второй стороной, надо знать хендл второй стороны.
13 апр 16, 15:27    [19052399]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Mike_za
перед получением в ресев, надо как-то отправить сообщение со второй стороны (авто активации то нет). а что бы прикинуться второй стороной, надо знать хендл второй стороны.
По-моему, вы пошли куда-то не туда.

Для организации уведомлений средствами SB нужно два сервиса и две очереди, одна из них с внутренней активацией.
Процедура активации занимается регистрацией подписчиков и их хендлов в служебной таблице. А также отпиской.
Уведомления рассылаются через вторую очередь.
13 апр 16, 16:41    [19052840]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
invm
Mike_za
перед получением в ресев, надо как-то отправить сообщение со второй стороны (авто активации то нет). а что бы прикинуться второй стороной, надо знать хендл второй стороны.
По-моему, вы пошли куда-то не туда.

Для организации уведомлений средствами SB нужно два сервиса и две очереди, одна из них с внутренней активацией.
Процедура активации занимается регистрацией подписчиков и их хендлов в служебной таблице. А также отпиской.
Уведомления рассылаются через вторую очередь.


ну вот и прояснилось))) я про ОДНУ очередь и ОДИН Сервис с первого топика говорил
13 апр 16, 17:02    [19052932]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Mike_za
я про ОДНУ очередь и ОДИН Сервис
В чем преимущество?
13 апр 16, 19:01    [19053449]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
invm
Mike_za
я про ОДНУ очередь и ОДИН Сервис
В чем преимущество?

Нет преимуществ, велосипед в процесе обучения, как обыно
13 апр 16, 20:26    [19053668]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8805
Владислав Колосов
Mike_za,

автор
сервиса общающегося самого с собой

Таких не бывает, всегда общаются два "контрагента".
13 апр 16, 22:17    [19053931]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Владислав Колосов
Владислав Колосов
Mike_za,

пропущено...

Таких не бывает, всегда общаются два "контрагента".

Имелось в виду, что Сервис имеет то же имя
13 апр 16, 22:24    [19053944]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Ну хорошо.
Пусть 2 отдельных сервиса. Подписка осуществляется активационной процедурой.
Но для осуществления подписки эта процедура должна зарегистрировать в таблице подписке свой хендл разговора (берется из recieve) + некий идентификатор подписчика. Ид подписчика надо передать внутри запроса на подписку?

Или обратный вариант. Сервис регистрации отправит обратно свой хендл. И уже запросивший регистрацию зарегистриует его + ид, который на руках.
13 апр 16, 22:29    [19053951]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Mike_za
Но для осуществления подписки эта процедура должна зарегистрировать в таблице подписке свой хендл разговора (берется из recieve) + некий идентификатор подписчика. Ид подписчика надо передать внутри запроса на подписку?
Хендл диалога и будет id'ом подписчика.
13 апр 16, 23:32    [19054016]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8805
Надо понимать, как осуществляется сделка между людьми. Здесь MS проводит полную аналогию.

Имеем двух контрагентов, которые заключают контракт, т.е. договор.
Обе стороны подписывают контракт, у каждой из сторон есть право расторгнуть контракт. Условие расторжение контракта - подписание обеими сторонами документа о расторжении.
Во время действия контракта осуществляется обмен заказными сообщениями с уведомлениями.
При заключении контракта оговаривается терминология.

Таким образом, получаем:

контрагентов (сервисы)
терминологию договора (тип сообщения)
договор (контракт)
очереди обработки входящей и исходящей корреспонденции (очереди сообщений).
14 апр 16, 00:22    [19054073]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Ок...... Видимо я снова плохо объяснил, что хочу сделать.

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

При начале работы подписчик создает подписку,
В процессе работы добавляет в нее статьи, которые и надо отслеживать.
Я не создаю для каждого из них свои тип "подпиши меня. Я 1 подписчик", "я 2"
Они все подписываются одинаковым сообщением "подпиши меня". В теле сообщения нет доп информации.

В момент создания подписки
0. Подписчик открывает диалог и говорит: подпиши меня.

1. Таргет выгребает из очереди просьбу от подписчика. Создает запись в таблице "подписка" и Сохраняет хендл полученный с сообщением из очереди. (Тот через котопый может слать ответ)

Если он сейчас не вернет инициатору (источнику-подписчику) ид подписки, (либо свой хенд) в теле сообщения, то каким образом несколько подписчиков смогут добавлять новые статьи, или получать свои оповещения об кстаревании?
14 апр 16, 02:08    [19054123]     Ответить | Цитировать Сообщить модератору
 Re: Натификация с сервера  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Пока писал, кажется, сам понял.

Подписчик в свою таблицу должен был сохранит свой хендл.
При добавлении новой статьи, он должен послать сообщение таргету. Тогда таргету становится все равно какой именно пришел подписчик, он по хенлу выгребает подписку, добавляет новую статью и тп.
В случае сброса , любая проца на сервере находит статью, и отправляет по хендлу таргета сообщения подписчику... А подписчик сидит и слушает очередь про свой хендл.

Так вот... Добавлений статей - получение нового кеша должно быть синхронно и без очередей.
Соответственно - это просто вставка пары записей в таблицы.
Очереди же нужны только на события сбпроса и там допустим асинхрон
14 апр 16, 02:30    [19054130]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить