Здравствуйте, Sheridan, Вы писали:
S>Ты наверное не понял какой хидер я имел ввиду. А имел ввиду я чтото типа header.h приблизительно такого содержания: S>
Здравствуйте, Sheridan, Вы писали:
A>> на обеих сторонах поменять *очень* сложно. а добавление хидера (т.е. метаинформации), с возможностью расширения/изменения чего угодно, я боюсь, как раз и приведет к появлению у тебя xml/binary xml/asn.1/что-то еще похожее. S>Ты наверное не понял какой хидер я имел ввиду.
Скорее ты не понял сути проблемы. Проблема в том, что клиент и сервер в общем случае могут писать разные конторы. Мало того — одновременно несколько контор могут писать несколько разных версий и клиента, и сервера. Соответственно, если ты собираешься задавать размерность какого-то поля, тупо указывая ему тип в хедере — то тебе придется выдумать некий механизм, который заставит перейти на новую версию хедера одновременно все эти конторы. Потому как если на новый размер поля перейдет только часть из них — в системе тут же начнется вавилонское столпотворение, клиенты и серверы от разных производителей попросту перестанут понимать друг друга.
Здравствуйте, Пацак, Вы писали:
П>Проблема в том, что клиент и сервер в общем случае могут писать разные конторы.
Даже если и одна контора. При изменении типов придется либо обновлять все ПО, чтобы оно понимало новый формат, причем единовременно. Либо вносить изменения так, чтобы старые клиенты понимали новый формат без изменений — получится очередной legacy-костыль, множество которых можем наблюдать в низкоуровневой области: если такой-то флаг не установлен, то значение находится по такому-то смещению, если установлен — то по такому-то смещению лежит младшая часть значения, а по такому-то — адрес, где искать старшую часть, и т.п.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Приветствую, ДимДимыч, вы писали:
ДД> А если float'ы на разных машинах разного размера? Если разное внутреннее представление float'ов или просто разный порядок байт?
Я в курсе. В этом случае смотри реализацию того-же NMEA. Это максимум, на что можно пойти в крайнем случае.
Но вот скажи мне — часто ли тебе приходилось в тобой писанном проекте обмениваться данными с компами другой архитектуры?
Приветствую, Пацак, вы писали:
П> Скорее ты не понял сути проблемы. Проблема в том, что клиент и сервер в общем случае могут писать разные конторы. Мало того — одновременно несколько контор могут писать несколько разных версий и клиента, и сервера.
Да ну? Не может быть!?
П> Соответственно, если ты собираешься задавать размерность какого-то поля, тупо указывая ему тип в хедере — то тебе придется выдумать некий механизм, который заставит перейти на новую версию хедера одновременно все эти конторы. Потому как если на новый размер поля перейдет только часть из них — в системе тут же начнется вавилонское столпотворение, клиенты и серверы от разных производителей попросту перестанут понимать друг друга.
Механизм очень простой. Называется "предупреждаем и меняем". Для этого:
а) это должен быть опенсорц (в принципе неважно, цель — открытые для интересующихся исходники)
б) Намерение внести изменения обязаны быть предварительно сообщено заинтересованным
в) Переход должен осуществляться сразу и в намеченный срок. В крайнем случае возможно что старое поведение оставляется с пометкой "устарело" на четко оговоренный срок.
И не надо плакать на пердмет "все не успеют, так нельзя, чтото отломается". Да не успеют, причем большинство. Это их личные проблемы. Если их проблемы касаются и вас — помогайте. Точка.
Почему я должен расжевывать тут то, что вы должны понимать сами?
Приветствую, ДимДимыч, вы писали:
ДД> Здравствуйте, Пацак, Вы писали:
ДД> П>Проблема в том, что клиент и сервер в общем случае могут писать разные конторы.
ДД> Даже если и одна контора. При изменении типов придется либо обновлять все ПО, чтобы оно понимало новый формат, причем единовременно. Либо вносить изменения так, чтобы старые клиенты понимали новый формат без изменений — получится очередной legacy-костыль, множество которых можем наблюдать в низкоуровневой области: если такой-то флаг не установлен, то значение находится по такому-то смещению, если установлен — то по такому-то смещению лежит младшая часть значения, а по такому-то — адрес, где искать старшую часть, и т.п.
Блин, каааак страшно жить, а? Ей богу. Вас почитаешь тут — так надо пользователей ватой обложить, 15ти-метровым слоем. А разработчиков и того больше, метров под 40.
Чтобы не дай бог не перетрудились, бедняги.
Не хотите костылей — делайте правильно сразу! Для этого проводите исследования, в которых попытайтесь учесть все возможные направления.
А то как маленькие, ей богу. "Нет, мы не будем мучаться и писать быстро работающий и потребляющий мало траффика протокол. Нам както не с руки думать о том, что может понадобиться в будущем. Мы лучше возьмем xml и http, потомучта там уже все есть. Правда это разрабатывалось не для наших целей, но ниче нам подойдет, хотя и придется дополнительно нагружать систему потоковым сжатием наших данных. Зато нам напрягаться ненадо будет. А вот когда поймем что херню по сети передаем, то тогда просто допишем и будем в два раза больше херни по сети передавать. Старую херню и новую. А удалять передачу старой херни — нини! А то вдруг у Петра Васильича из поселка Залукокоаже его нетленка работать перестанет! Он же нам не простит никогда!"
Все верно описал? Ничего не упустил?
И еще раз спрошу: Почему я должен тут расжевывать вещи, которые вы должны, повторяю — должны знать и понимать сами?
Здравствуйте, Sheridan, Вы писали:
П>> Скорее ты не понял сути проблемы. Проблема в том, что клиент и сервер в общем случае могут писать разные конторы. Мало того — одновременно несколько контор могут писать несколько разных версий и клиента, и сервера. S>Да ну? Не может быть!?
Точно-точно!
S>Механизм очень простой. Называется "предупреждаем и меняем".
S>Для этого: S>а) это должен быть опенсорц
Что "это", Шеридан? Напоминаю: код пишут несколько фирм. Конкурирующих фирм. Разный код. Независимо друг от друга. Все, что их объединяет — это протокол. Ты его хочешь поменять. Объясни мне, как ты обеспечишь синхронный переход на этот протокол всех участников рынка? И что ты будешь делать со старыми, уже установленными серверами и клиентами?
S>б) Намерение внести изменения обязаны быть предварительно сообщено заинтересованным S>в) Переход должен осуществляться сразу и в намеченный срок. В крайнем случае возможно что старое поведение оставляется с пометкой "устарело" на четко оговоренный срок.
О, да-а-а! Напомнить тебе, когда IETF озвучили намерение ввести IPV6?
S>И не надо плакать на пердмет "все не успеют, так нельзя, чтото отломается". Да не успеют, причем большинство. Это их личные проблемы.
Не, Шеридан. Это твои, как разработчика протокола, проблемы. Потому как если в работе с новой версией начнутся подобные грабли — это немедленно вызовет ее отторжение у обломавшихся пользователей. И в результате ты рискуешь как минимум не ввести ее вообще никогда. Как максимум — потерять и тех, кто использовал старую версию.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Даже если и одна контора. При изменении типов придется либо обновлять все ПО, чтобы оно понимало новый формат, причем единовременно. Либо вносить изменения так, чтобы старые клиенты понимали новый формат без изменений — получится очередной legacy-костыль, множество которых можем наблюдать в низкоуровневой области: если такой-то флаг не установлен, то значение находится по такому-то смещению, если установлен — то по такому-то смещению лежит младшая часть значения, а по такому-то — адрес, где искать старшую часть, и т.п.
На самом деле есть еще третий вариант, про который Шеридан почему-то не вспоминает (не знает?) — дописывать ко всем атрибутам значение их длины. Как это делается в том же RADIUS, например. В итоге все будет круто, быстро и практически без оверхеда. Не считая только одного малюсенького облома: длина длины сама по себе может поменяться.
Приветствую, Пацак, вы писали:
П> Здравствуйте, ДимДимыч, Вы писали:
П> ДД>Даже если и одна контора. При изменении типов придется либо обновлять все ПО, чтобы оно понимало новый формат, причем единовременно. Либо вносить изменения так, чтобы старые клиенты понимали новый формат без изменений — получится очередной legacy-костыль, множество которых можем наблюдать в низкоуровневой области: если такой-то флаг не установлен, то значение находится по такому-то смещению, если установлен — то по такому-то смещению лежит младшая часть значения, а по такому-то — адрес, где искать старшую часть, и т.п.
П> На самом деле есть еще третий вариант, про который Шеридан почему-то не вспоминает (не знает?) — дописывать ко всем атрибутам значение их длины. Как это делается в том же RADIUS, например. В итоге все будет круто, быстро и практически без оверхеда. Не считая только одного малюсенького облома: длина длины сама по себе может поменяться.
Все это имеет смысл при разработке действительно кроссплатформенного (кроссархитектурного?) софта. Пока мы находимся под одной архитектурой (а большинство местных — вообще ограничено только виндами) — то и лепить все это к протоколу смысла нет.
Приветствую, Пацак, вы писали:
П> S>Механизм очень простой. Называется "предупреждаем и меняем".
П> Что "это", Шеридан? Напоминаю: код пишут несколько фирм. Конкурирующих фирм. Разный код. Независимо друг от друга. Все, что их объединяет — это протокол. Ты его хочешь поменять. Объясни мне, как ты обеспечишь синхронный переход на этот протокол всех участников рынка? И что ты будешь делать со старыми, уже установленными серверами и клиентами?
Я буду просто требовать соблюдения протокола. Точка. Больше ничего не надо.
П> S>б) Намерение внести изменения обязаны быть предварительно сообщено заинтересованным П> S>в) Переход должен осуществляться сразу и в намеченный срок. В крайнем случае возможно что старое поведение оставляется с пометкой "устарело" на четко оговоренный срок.
П> О, да-а-а! Напомнить тебе, когда IETF озвучили намерение ввести IPV6?
И что? Они убрали IPV4? Нет. Если бы убрали — давно бы все на шестерке сидели.
П> S>И не надо плакать на пердмет "все не успеют, так нельзя, чтото отломается". Да не успеют, причем большинство. Это их личные проблемы.
П> Не, Шеридан. Это твои, как разработчика протокола, проблемы. Потому как если в работе с новой версией начнутся подобные грабли — это немедленно вызовет ее отторжение у обломавшихся пользователей. И в результате ты рискуешь как минимум не ввести ее вообще никогда. Как максимум — потерять и тех, кто использовал старую версию.
Гы. Ты как минимум смешной. Априори я, как разработчик протокола, обязан его тестировать. Я, как разработчик протокола обязан его улучшать и делать задел на будующее. Наклепа мне выпускать новую версию протокола с возможными граблями? Чтобы ты порадовался.
Нет, уважаемый, не болтай ерундой. Не надо пытаться уйти от разговора о том, что сейчас программисты пошли дурные и лепят херню всякую слева направо. (а разговор то об этом. Это я тем, кто между строк читать не умеет.) Лишь бы работало. А сколько там будет оно траффика потреблять, памяти, ресурсов вообще — практически всем наложить. Вооооот такую вот кучу. И когда вам начинаешь говорить — "уважаемые, ну назачем вы так потребляете ресурсы, это же можно сделать намного легче!" — получаешь в ответ столько тонн дерьма от крутых перцев, что диву даешься — либо отупели, либо просто понятия не имеют что можно по другому делать. И с одной стороны их можно понять — спешат кудато. Но с другой то стороны — халтура же, чистой воды халтура. И когда я от программиста слышу нечто типа "сетевой протокол надо писать на xml+http" — я понимаю — поисписался несколько программист. Ну сам то поисписался — ладно, херня. Его проблемы. Но нахрена то молодых учить делать также, а? Они-ж вам, блин, в рот заглядывают.
Не понимаю, вобщем, абсолютно не понимаю.
Я пытаюсь вам объяснить очевидные же вещи, абсолютно очевидные. А в ответ что? В ответ отрицание, сквозь которое явно проглядывает либо бешенная спешка, либо лень. Может хватит? Я могу понять и спешку и лень. Я не могу понять — почему отрицание?
Здравствуйте, ДимДимыч, Вы писали:
ДД>Это я уже прочитал и понял. Но меня не покидает стойкое ощущение, что сразу после запуска какое-то время работало без "let", хотя понимаю, что никак не могло. Такой вот интересный психологический глюк.
Закусывать надо (С) "Иван Васильевич меняет профессию"
Здравствуйте, Sheridan, Вы писали:
S>Я буду просто требовать соблюдения протокола.
У кого и как ты этого будешь требовать? Для большинства разработчиков ты нет никто и звать тебя никак, что ты там себе думаешь по поводу твоего суперпротокола их волнует мало. Сегодня они тебя поддерживают, а завтра им твои изменения не понравятся и ты будешь незамедлительно послан на три буквы. В особо тяжелых случаях — вместе с твоим протоколом.
П>> О, да-а-а! Напомнить тебе, когда IETF озвучили намерение ввести IPV6? S>И что? Они убрали IPV4? Нет.
Нет, правда — сильно интересно, как ты себе это представляешь? "Мы, Шеридан Восемнадцатый, сим повеливаем с завтрашнего дня делать все рельсы на х.. шире, а напряжение во всех розетках увеличить до 450 Вольт"?
S>Если бы убрали — давно бы все на шестерке сидели.
Ну да, все 0.0001% тогдашнего интернета. Остальные бы послали IETF куда подальше и остались на старой версии. Они, кстати, в итоге на ней и остались.
S>Гы. Ты как минимум смешной. Априори я, как разработчик протокола, обязан его тестировать.
Шеридан, открой секрет, что ты понимаешь под словом "протокол"? Я так подозреваю, что как обычно — что-то своё, особенное. На всякий случай хинт: это совсем не то же самое, что "программа".
S>Наклепа мне выпускать новую версию протокола с возможными граблями?
Вот и мне интересно — зачем тебе нужен такой протокол, малейшее изменение в котором вызовет "личные проблемы" у подавляющего большинства тех, кто его реализует и использует? Это ведь даже не грабли — это мегаграбли, с самурайским мечом вместо рукоятки.
S>Нет, уважаемый, не болтай ерундой. Не надо пытаться уйти от разговора о том, что сейчас программисты пошли дурные и лепят херню всякую слева направо.
Я таких в этом топике не видел. Пока я тут вижу только одного дурного админа, к тому же явно страдающего завышенной самооценкой. Вот он — да, лепит фигню. Но он вообще частенько ее лепит, так что скорее всего это уже дань традиции.
Здравствуйте, Sheridan, Вы писали:
S>Все это имеет смысл при разработке действительно кроссплатформенного (кроссархитектурного?) софта.
Это имеет смысл всегда, когда ставится целью получить расширяемый двоичный формат. В том числе и в твоем случае — для относительно безболезненной замены float на double без изменения самого протокола. Но ты вместо этого предпочитаешь менять несуществующие "общие хедеры".
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, anton_t, вы писали:
a>> S>на обеих сторонах (клиент, сервер) в структурах меняю float на double. Хотя почему на обеих... Хидер же один будет, если правильно писать. a>> Гы-гы. Святая простота. А теперь представь, что такая замена происходит с системой GPS. Все старые приёмники выбрасывать? Или все разом в сервис на прошивку нести? S>гпс я приводил в качестве примера данных. Не цепляйся к нему. И если такая ситуация может возникнуть, то значит надо предугадывать заранее. Если вы пишете какойто протокол, который __может быть__ когдато расширится, то надо предугадать это расширение и сделать все возможное для его простоты. Вспомни хотябы кадры wifi — даже там есть зарезервированные байты\группы байтов.
Лично у нас в конторе штатные телепаты не предусмотрены. И в прошлой моей конторе тоже не были предусмотрены. Телефончик телепатов не подкинешь? Может разработка веселее пойдёт.
Здравствуйте, Sheridan, Вы писали:
S>А то как маленькие, ей богу. "Нет, мы не будем мучаться и писать быстро работающий и потребляющий мало траффика протокол. Нам както не с руки думать о том, что может понадобиться в будущем. Мы лучше возьмем xml и http, потомучта там уже все есть.
Да, потому что получится быстро работающий и потребляющий мало трафика протокол. S>И еще раз спрошу: Почему я должен тут расжевывать вещи, которые вы должны, повторяю — должны знать и понимать сами?
Шеридан, мы всё, что нужно, понимаем и знаем. Я тебе уже предложил наваять на коленке твой протокол для передачи GPS. Чтобы ты лично смог убедиться, что HTTP рвёт наколенную поделку. Но что-то ты не спешишь это делать — зато столько гонору в обучении нас, тупых, проектированию протоколов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Но вот скажи мне — часто ли тебе приходилось в тобой писанном проекте обмениваться данными с компами другой архитектуры?
Вот у меня, пока я тут пишу, мой комп обменивается сообщениями с компами другой архитектуры. Говорят, с той стороны железо поменяли. Похоже на правду: у меня время ожидания ответа уменьшилось. Но наш софт как работал, так и работает. Потому что протокол.
А вообще скажи: тебя сильно волнует, какой архитектуры комп отвечает твоему браузеру?
Здравствуйте, Sheridan, Вы писали:
S>Нет, уважаемый, не болтай ерундой.
Чем-чем?
S>Не надо пытаться уйти от разговора о том, что сейчас программисты пошли дурные и лепят херню всякую слева направо. (а разговор то об этом. Это я тем, кто между строк читать не умеет.) Лишь бы работало. А сколько там будет оно траффика потреблять, памяти, ресурсов вообще — практически всем наложить.
Самый ценный ресурс в процессе разработки, IMHO,— время разработчика. И если разбазаривать его, пытаясь решить несуществующие (давно решенные) проблемы, эти затраты никогда не будут покрыты за счет экономии любых других ресурсов. Другое дело, что писать надо аккуратно. Не делать, например, так:
S> M> Именно так. ГУЙ в браузере на несколько порядков сложнее нативных ГУЕв и при этом отрисовывается не просто быстро, а сверхбыстро. И при этом таки да, потребляет меньше ресурсов
S> Да? firefox. Теперь про html рендеры спорить будем?
Шеридан, ты клинический идиот. Да, мы говорим про HTML-рендеры. Потому что GUI самого браузера зачастую нативный.
S> M> Ты бы эта, хоть раз прежде чем нести полную чушь, открыл гугл и википедию и почитал бы, а? Открой главную страницу RSDN'а и найди там хоть один нативный контрол. Вперед.
S> Пользуешься тем что спай глубже ieframe не ныряет?
Шеридан, ты клинический идиот. Открываешь каждый фрейм отдельно, вообще заходишь на любой сайт и находишь мне там хоть один нативный контрол (кроме указаного уже селекта). Вперед.
S> M> Выполнение байт-кода в виртуальной машине не является интерпретацией.
S> О даааа. Выполнение какбы нативного какбы ассемблера на виртуальной машине это какбы и не интерпритация совсем, да? Слова то крутые? Виртуальная машина, байт-код. Крутые. Модные? Модные. Ну значит и не интерпритация.
Вообще-то, виртуальным машинам сто лет в обед. И твои представления об интерпретации и компиляции настолько удалены от реального положения вещей, насколько только возможно, и еще чуть чуть.
S> M> S>Далее, протоколы. Про sock5 ты видимо не слышал. Про сжатие вообще помолчи, смешно же ведь. Сжимать имеет смысл только текст.
S> M> А так же видео, аудио, да и вообще все подряд, если это надо передавать по сети.
S> Ох мамут такой мамут... Ты не в курсе, что аудио и видео уже какбы сжаты. И их дальнейшее сжвтие приведет а) к потере качества и б) к накладнвм расходам на стороне сервера и возможно на стороне клиента (если нестандартное чтото).
Шеридан такой Шеридан. Например, Silverlight (емнип) умеет прогрессивно менять уровень сжатия видео, чтобы компенсировать такие вещи, как падение пропускной способности канала, повышение латентности в канале и т.п. Правда, о том, что такая возможность может понадобиться, до тебя вообще никогда в жизни бы не дошло.
S> Я не против сжатия. Я против бездумного его применения в качестве костылей к протоколу дабы выглядело хоть както по божески.
Ты просто не имеешь понятия ни что такое сжатие, ни что такое стандартизированые протоколы, ни что такое накладные расходы, ни что такое костыли.
S> M> S>А если нам текст нахрен не нужен? Ну к примеру gps данные шлем, а? Нахрена тут сжатие? Сам прикинешь на сколько порядков меньше траффика будет? Или ты забыл, что бинарные данные тоже отправлять можно? http протокол голову забил?
S> M> Тебе лично голову забили твои фантазии без единой крупицы знаний, логики и желания думать
S> Да? вот координата: 12.223344, 120.123321, высота: 305,42м, скорость 52.34км\ч. Итого 4 float или минимум 34 char (12.223344 120.123321 305.42 52.34\n) на данные.
О да. А направление? А поворот в градусах? А высота на уровнем моря (для точного топографического отображения)
S> Посчитаем? 4*4 = 16 байт для 4х float и 1 * 34 = эээ.... 34? S> Ах да. Вы же так никогда не сделаете. Точно, как я мог такое подумать. У вас же xml в головах прошит. Будет чтото типа <data lattitude="" longlitude="" height="" speed="" /> как минимум. Будем считать байты?
Тебе сто пятьдесят раз говорили, что телепат из тебя хреновый. Ах, да «системные администраторы всегда могут посмотреть в гугле или википедии, а программисты не могут».
Ну ка посмотрим...
есть общепринятый стандарт работы такого оборудованива (я о gps сейчас)
NMEA («National Marine Electronics Association») — полное название «NMEA 0183» — текстовой протокол связи морского (как правило, навигационного) оборудования между собой. Стал особенно популярен в связи с распространением GPS приёмников, использующих этот стандарт. (В настоящее время внедряется стандарт «NMEA 2000»).
Что делает крутой сисадимн Шеридан? Он идет в гугль проверить, что это такое? Нет, они начинает бурно фантазировать на темы,в которых нихрена не разбирается. У него вдруг текстовый протокол приравнялся к XMLю. Ну и понеслася.
S> Вы слишком тут прыгнули вперед, напрочь забыв о логике в погоне за модными направлениями и прочей ерундой.
Нет Шеридан. У нас наоборот есть и логика и знания, и — самое главное — желаение получать эти знания. Ничего этого у тебя не наблюдается даже в помине.
Здравствуйте, Sheridan, Вы писали:
ДД>> А если float'ы на разных машинах разного размера? Если разное внутреннее представление float'ов или просто разный порядок байт? S>Я в курсе. В этом случае смотри реализацию того-же NMEA. Это максимум, на что можно пойти в крайнем случае.
Ты у нас эксперт по протоколам и их использованию, чтобы говорить о максимуме?
Не понял, что значит твой пассаж о "крайнем случае" в NMEA?
S>Но вот скажи мне — часто ли тебе приходилось в тобой писанном проекте обмениваться данными с компами другой архитектуры?
Только этим по работе и занимаюсь. Начиная с 8-битных AVR и до MIPS32. На костыли из-за умников, которые не рассчитывали, что бывают другие архитектуры, насмотрелся предостаточно.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
