Кинули утром:

Захотелось мне посмотреть распределение своего флуда в конфах по времени. Получилось нечто типа следующего:

!muc stat day

Message statistic for "Гадский демон":
Mon  |#################### (75)  
Tue  |# (4)                      
Wed  |## (10)                    
Thu  | (0)                       
Fri  |################# (64)     
Sat  |##### (21)                 
Sun  |##### (20)

!muc stat hour

Message statistic for "Гадский демон":
00:00  |#################### (43)  
01:00  |########## (23)            
02:00  |### (7)                    
03:00  | (0)                       
04:00  | (0)                       
05:00  | (0)                       
06:00  | (0)                       
07:00  | (1)                       
08:00  | (0)                       
09:00  |### (8)                    
10:00  | (0)                       
11:00  | (0)                       
12:00  | (0)                       
13:00  |# (4)                      
14:00  |################ (36)      
15:00  |######## (18)              
16:00  | (0)                       
17:00  | (0)                       
18:00  | (2)                       
19:00  |# (3)                      
20:00  |####### (17)               
21:00  | (0)                       
22:00  |######## (19)              
23:00  |###### (14)

Плохо, что инфа есть в базе только с 03.06.2009 ;)

За сутки уже набежало:

gluxi=> select count(*) from conference_log;
 count
-------
 35717
(1 row)

Интересно, на сколько глупой идеей это было и как скоро это всё начнет тормозить?

Вот в rfc3921, p.4.1. сказано:

4.1.  Specifying an Intended Recipient

   An instant messaging client SHOULD specify an intended recipient for
   a message by providing the JID of an entity other than the sender in
   the 'to' attribute of the <message/> stanza.  If the message is being
   sent in reply to a message previously received from an address of the
   form <user@domain/resource> (e.g., within the context of a chat
   session), the value of the 'to' address SHOULD be of the form
   <user@domain/resource> rather than of the form <user@domain> unless
   the sender has knowledge (via presence) that the intended recipient's
   resource is no longer available.  If the message is being sent
   outside the context of any existing chat session or received message,
   the value of the 'to' address SHOULD be of the form <user@domain>
   rather than of the form <user@domain/resource>.

То есть получается, что первые сообщения всегда отсылаются на bare JID (без ресурса). После первого же ответа нужно начинать отвечать уже на full JID, и так до тех пор, пока ресурс не станет недоступным.

Отсюда два вопроса:

1. Что делать, если у собеседника появляется ресурс с более высоким приоритетом? Продолжать отсылать сообщения на “старый” ресурс или переключаться на новый?
2. “Забывать” ли кратковременно недоступный ресурс (например после реконнекта собеседника)? А если как раз в момент реконнекта появляется ресурс с более высоким приоритетом?

В RFC оба случая не описаны (Про Conversation Thread знаю).

Собственно вот:

Осталось каждому смайлу присвоить GUID вида {986c11d0-f340-11d4-9075-0010a4e73d9a} и хранить их список в вендовом реестре…

/me в поисках другого глобуса.

http://clubs.ya.ru/4611686018427387973/:

Друзья, сложилась следующая ситуация:
1. У меня нет времени поддерживать работоспособность сервера.
2. Заинтересованных в копании этого говна более нет.
3. Донаты, на которые я бы мог приобрести помощь со стороны третьих лиц, не поступают уже очень давно.

Выводы:
у меня нет времени, а остальные незаинтересованы.
Предложение:
Предлагаю закрыть Jabbus.org c 1-го ноября 2008 г.


/me ожидает толпы лузеров, пытающихся вернуть конфы с JID-ами owner-ов на jabbus.org

Поделились травойJID-ом:

[22:42:28]  !user disco conference.radio-t.com
[22:42:29]  dion: Disco items:
1) online [online@conference.radio-t.com]: 171
2) talks [talks@conference.radio-t.com]: 0

170 человек… Первый раз вижу Jabber-конференцию с таким количеством народу. При чем русскоязычную.

Это я не знаю, что нужно было сделать с клиентом, чтобы он спамил одинаковыми презенсами каждые 5 секунд:

<presence from="xxx@ezxdev.org/Home" xml:lang="ru" to="xxx@inhex.net/Psi" >
<priority>5</priority>
<c xmlns="http://jabber.org/protocol/caps" node="http://miranda-im.org/caps" ver="0.8.0.19" ext="secureim mood activity" />
<status>Я здесь!</status>
</presence>

Я так понимаю, что Miranda нормально не только IRC не умеет.

Ниче, Privacy lists таки не зря предумали.. Прорвемся

Гладиолус: Pong from Гладиолус after -85601.2 secs.

<message from='***@conference.jabber.ru/Зомби' to='gluxi@inhex.net/GluxiBot-dev' xml:lang='en' type='groupchat'>
   <body>Гладиолус: Pong from Гладиолус after -85601.2 secs.</body>
</message>
</pre>

PS. Кроме какого-то переполнения на ум ничего не приходит… С другой стороны, на пинги таймаут стоит, который гарантированно влезит в long…

Мне таки кажется, что на jabber.ru установлен какой-то умный шейпер не только на c2s но и на s2s. Станзы <presence /> и <iq /> доставляются моментально, а <message /> тормозят… Очень похоже, что есть ограничение в количество станз в единицу времени на все конференции.

Судя по тому, что с другими серверами, вроде jabbus.org все нормально, это таки не канал.

Надо будет как-то померять что-то.