- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
len += sprintf(event_xml_msg, XML_TAG_START, XML_KOKOKO_HTTP_PROTOCOL);
// Set <monitor-event>
len += sprintf(strend_ptr(event_xml_msg), XML_TAG_START, XML_MONITOR_EVENT_NODE_TREE);
// Set <date>
len += xml_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_DATE, dt.date_b);
// Set <time>
len += xml_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_TIME, dt.time_b);
// Set <product> Ex. "VersAtive"
len += xml_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_PRODUCT, product_type);
// Set <entity code>
// Supposed to work for all union types
len += xml_int_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_CODE, event_code);
// Set <severity>
// len += xml_int_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_SEVERITY, severity);
memset(severity_str, 0, sizeof(severity_str));
get_severity_string(severity, severity_str);
len += xml_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_SEVERITY, severity_str);
// Set event entity name
len += xml_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_ENTITY_TYPE, entity_name);
// Set event description
if((len + strlen(description)) > (payload_size - footer_size))
{
// TODO HANDLE
printf("Message description overflows buffer size.\n");
return false;
}
len += xml_cdata_string_add_tag(event_xml_msg, XML_MONITOR_EVENT_NODE_DESCRIPTION, description);
// Set params
add_xml_entity_params(event_xml_msg, entity_params);
// Close <monitor-event>
sprintf(strend_ptr(event_xml_msg), XML_TAG_END, XML_MONITOR_EVENT_NODE_TREE);
// Close <HTTPProtocol>
len += sprintf(strend_ptr(event_xml_msg), XML_TAG_END, XML_KOKOKO_HTTP_PROTOCOL);
В проекте широко используется libmxml, а вот блять использовать его по назначению велосипедики не могут.
Follow us!
p.s: Прошу админов выпилить коммент с product name из ГК.
админы не читают комменты
ищи внизу "обратная связь", но шансов на успех около 1%
Простите, что?
@
Налетай на проблемы с экскейпингом
----------
На все замечания про готовые решения
@
Отвечай что они медленные, а для такой простой задачи хватит и printf
И шанс на переполнение буфера ну никак нельзя было упустить...
P.S. Или в footer_size уже учтена длина сериализованных entity_params и обертка в виде CDATA вокруг description?
Кроме того, весь payload ограничен 4 КБ.
Ну типа автор на 146% уверен, что всё, что ниже description'а (и обертка вокруг него тоже) всяко меньше, чем 128 байт...
Т.е. переполнение буфера подтверждается: даже если все эти add_xml_* растягивают буфер (что маловероятно), sprintf'ы в 41 и 44 - нет.
int xml_string_add_tag(char *msg, const char *tag, const char *val)
{
return sprintf(strend_ptr(msg), XML_TAG_START"%s"XML_TAG_END, tag, val, tag);
}
А эти макро вообще шедевр:
#define XML_GET_NAME(node) ((char *)((mxml_node_t *)(node)->value.element.name))
#define XML_GET_VALUE(node) ((char *)((mxml_node_t *)(node)->value.opaque))
ЕМНИП, в говномамонтной версии либы нормальных геттеров не было.
XML логирование по UDP поди?
Так сложно сделать реконнект?
Да и если канал постоянно рвется то половина логов просто протеряется
Можно и так:
1) положить в буфер
2) подождать N милисекунд
3) попробовать снова
Ну а если буфер переполница то старые выкидывать.
Система будет куда как надежнее.
-------
Но UDP зато можно стримить и собирать на 150 серверов независимо.
Куда-то то уж точно дойдет. А при наличии IGMP стримить можно и в другую сеть!
В точку!
1) логи для статистики (перформанс, кол-во юзерей, время ответа, загрузка CPU, какие-то факты для OLAP кубов-репортов итд). Часть таких логов можно продолбать и аппроксимировать.
2) логи секьюрити (например логин пользователя в систему или транзакция -- перевод миллиарда долларов на счет). Вот такие логи я бы не рискнул по UDP без подтверждения доставки;)
TCP гарантирует только порядок байт в потоке. Не более того.
Это вполне гарантирует TCP.
Что неправильно?
Гарантии TCP - порядок байт в потоке и их корректность.
А UDP не поставит.
И кстати в случае порванного провода Вы никак не гарантируете.
Ну не поставит же. А если и поставит - то только по таймауту. И не скажет, какие именно байты проёбаны. Один хрен свои подтверждения прикручивать придётся. И, в итоге, мы получим окно поверх окна.
> в случае порванного провода Вы никак не гарантируете
В том и суть. Что гарантии у систем на основе TCP и UDP будут примерно одинаковые. Только с TCP, в данном случае, больше ёбли.
Значит, писун узнает что читун отвалился.
Вот! И тут-то TCP, вместо того, чтобы помогать, начинает втыкать нам палки в колёса.
Добавляем записи в "очередь" ограниченной длины. У каждой записи есть время переотправки (resend_time), ttl и priority. Поток отправляет записи с resend_time > now, при этом у записи увеличивается resend_time (по формуле, зависящей от ttl) и уменьшается ttl (если дошел до 0 - запись удаляется). При получении подтверждения соответствующие записи вычеркиваются из очереди. При переполнении очереди отбрасывается самая старая запись с priority <= приоритету вставляемой записи. Как-то так.
> а не over TCP
Потому, что буфера, таймауты и окна TCP тут будут только мешать (хотя, с другой стороны, на TCP мы получим лучший congestion control).
И зачем портить TCP, если можно улучшать UDP? :)
Ой ли?
Святая наивность... Если кабель выдрать у писуна - да, вернет, скорее всего. В остальных случаях - просто пообещает записать N байт и отложит в буфер до поры до времени.
Ну хорошо, не сразу вернется, ОС какое-то время будет копить данные в буфере, потом на канальном уровне это будет хендлится (сетевуха будет пытаться что-то сделать итд). Но в конце концов -1 все-таки вернется же!
Если не крутить настройки сокета - через 20-30 минут. Только это будет уже совсем другой write().
Если например на роутере беда и пришел по ICMP "Destination unreachable" то всё равно ждать пол часа?)
А если пакеты летят вникуда и там дропаются то и правда ждать можно долго. Но кроме того есть настройки, как Вы правильно сказали.
Ну чудес не бывает же. Мы же не можем понять потерялся пакет навсегда или просто еще не пришел.
Ну значит игра достаточно часто отправляла пакеты, и ICMP'шки хорошо пролезали...
А вот если выдрать кабель за каким-нибудь тупым коммутатором в локалке - скорее всего не узнают.
О какой ебле идет речь? TCP вполне себе реализован на большинстве платформ, тут ничего не надо пилить.
Кроме того в TCP (ЕМНИП) ресивер может крутить окно и тем самым говорить посылальщику "быстрее-медленее", чтоб буфер не переполнился
> XML
Блять.