Size: a a a

2020 February 13

S

Snusmumriken in pro.lua
Так, тогда ещё один вопрос: этот лог предназначен для чтения и парсинга машиной? Или только человеком?
источник

S

Snusmumriken in pro.lua
Потому что давай взглянем, например, на Redis:
https://redis.io/topics/protocol
источник

f

fgntfg in pro.lua
А давайте глядеть на бинарные логи от WAS? И ПЛАКАТЬ!
источник

S

Snusmumriken in pro.lua
Тут, вот неожиданность, есть абсолютно чётко выраженные длины сообщений в тех случаях, где это необходимо. Базовым разделителем является \r\n (чтобы не совокупляться с длиной каждый раз), но если принимаемый тип — строка, то там точно указана длина. Чтобы было понятно, сколько ещё принять от этой строки, и где закончилось сообщение. Redis предназначен для поддержания соединения неограниченно долго, и в него даже можно загнать десяток сконкатенированных запросов, и получить такой же десяток сконкатенированных ответов (пайплайн).
источник

S

Snusmumriken in pro.lua
И эта магия сделана как раз благодаря тому, что местный протокол совершенно точно и однозначно разделяет tcp-поток на отдельные сущности, вплоть до вложенных.
источник

S

Snusmumriken in pro.lua
Можно ещё посмотреть на магию с HttpChunked.
Ты только посмотри, как люди изгаляются, только для того чтобы узнать, где сообщение заканчивается.
https://ru.wikipedia.org/wiki/Chunked_transfer_encoding

Потому что иначе это просто не сделать.
источник

VV

V V in pro.lua
Snusmumriken
Так, тогда ещё один вопрос: этот лог предназначен для чтения и парсинга машиной? Или только человеком?
Хороший вопрос. Это ДОЛЖНА читать машина (слишком высокий eps для чтения человеком), но имеем то, что имеем.

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

VV

V V in pro.lua
Redis - один из примеров хорошей работы с tcp потоком. А с ними редко возникают проблемы)
источник

S

Snusmumriken in pro.lua
V V
Хороший вопрос. Это ДОЛЖНА читать машина (слишком высокий eps для чтения человеком), но имеем то, что имеем.

Да, если посмотреть на диалог того же smtp клиента, мы тоже увидим, что все сообщения разделены, и однозначно идентифицируются даже, когда у нас идёт приём нескольких сообщений в одном.
Но факт - не все разработчики так делают. Хотя было бы здорово, если бы делали.
Нене, eps — это не повод для чтения машиной. У меня на работе где-то 4000 логирующих сообщения в секунду (на луёвом TCP, кек), и оно предназначено для человека, который сделает запрос по базе. Все логи парсятся.
источник

S

Snusmumriken in pro.lua
Человек просто увидит что где проблема, сделает запрос по ID и получит логи которые можно прочитать. Остальное можно будет удалить.
источник

VV

V V in pro.lua
Snusmumriken
Нене, eps — это не повод для чтения машиной. У меня на работе где-то 4000 логирующих сообщения в секунду (на луёвом TCP, кек), и оно предназначено для человека, который сделает запрос по базе. Все логи парсятся.
Ок, тут речь о 25к в фоне
источник

S

Snusmumriken in pro.lua
Всё равно фигня.
источник

S

Snusmumriken in pro.lua
Регулярки и вперёд.
источник

VV

V V in pro.lua
Snusmumriken
Нене, eps — это не повод для чтения машиной. У меня на работе где-то 4000 логирующих сообщения в секунду (на луёвом TCP, кек), и оно предназначено для человека, который сделает запрос по базе. Все логи парсятся.
Логи парятся - это признак чтения машиной, нет?))
источник

S

Snusmumriken in pro.lua
Нет.
источник

VV

V V in pro.lua
Snusmumriken
Регулярки и вперёд.
Регулярки по текстовом файлу без конца?
источник

S

Snusmumriken in pro.lua
Это человек может составить регулярку чтобы найти конкретный кусочек.
источник

S

Snusmumriken in pro.lua
Почему без конца?
источник

VV

V V in pro.lua
Snusmumriken
Это человек может составить регулярку чтобы найти конкретный кусочек.
Это плохое решение.
источник

S

Snusmumriken in pro.lua
Кому-то может быть норм.
источник