Re[8]: Протокол HTTP
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.04.08 12:37
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму


Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п. Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Протокол HTTP и веб-сервисы
От: vb-develop  
Дата: 08.04.08 12:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vb-develop, Вы писали:

VD>>Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже.
S>Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
Какие, например? (так для общего развития)
Re[8]: Протокол HTTP и веб-сервисы
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.04.08 13:09
Оценка:
Здравствуйте, vb-develop, Вы писали:
VD>Какие, например? (так для общего развития)
Например искать по слову REST.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Протокол HTTP
От: Cyberax Марс  
Дата: 08.04.08 13:20
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

И>>Что касается двух версий протокола debug/release, это несерьезно.

PD>Не debug/release (я это просто в качестве примера привел), а просто двух версий. Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму, остальные суть содержимое запроса. Кстати, конвертировать из бинарного в текстовый мог бы сам сервер (IIS) перед передачей приложению, так что ты бы ничего и не заметил.
Это сейчас и так есть — называется gzip encoding.

Она не захватывает заголовки, но это не создаёт особой разницы кроме некторых упомянутых частных случаев.
Sapienti sat!
А что мы сейчас обсуждаем вообще?
От: Mamut Швеция http://dmitriid.com
Дата: 08.04.08 13:30
Оценка:
Сабж вобщем-то

Как-то мы плавно ушли с обсуждения HTTP на обсуждение непонятно чего непонятно о чем
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[5]: Протокол HTTP
От: Shabi  
Дата: 09.04.08 00:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Shabi, Вы писали:


И>>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.

S>>....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал
C>А функции типа htons/htonl видел?l

нет. эти?

Как известно, порядок байт в целых числах, представление которых занимает более одного байта, может быть для различных компьютеров неодинаковым. Есть вычислительные системы, в которых старший байт числа имеет меньший адрес, чем младший байт (big-endian byte order), а есть вычислительные системы, в которых старший байт числа имеет больший адрес, чем младший байт (little-endian byte order). При передаче целой числовой информации от машины, имеющей один порядок байт, к машине с другим порядком байт мы можем неправильно истолковать принятую информацию. Для того чтобы этого не произошло, было введено понятие сетевого порядка байт, т.е. порядка байт, в котором должна представляться целая числовая информация в процессе передачи ее по сети (на самом деле – это big-endian byte order). Целые числовые данные из представления, принятого на компьютере-отправителе, переводятся пользовательским процессом в сетевой порядок байт, в таком виде путешествуют по сети и переводятся в нужный порядок байт на машине-получателе процессом, которому они предназначены. Для перевода целых чисел из машинного представления в сетевое и обратно используется четыре функции: htons(), htonl(), ntohs(), ntohl().


не поленись перечитай то о чё писал я ....

(на всякий случай разжевываю. САМ протокол TCP/IP о проблеммах little/big endian НИЧЕГО незнает. ибо конкретно на этом уровне принято одно решение для всех. а вот на уровне приложения.... )



И>>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук.

S>>когда ты последний раз отлаживал TCP/IP?
C>Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня.

тоже иногда занимаюсь отлаживанием протоколов (чаще бинарных)....да мои отладчики несколько сложнее, чем примитивный notepad. но как то грусти совершенно никакой нет.

но я писал не о том на что ты отвечал.
Re[8]: Протокол HTTP
От: Shabi  
Дата: 09.04.08 01:25
Оценка:
Здравствуйте, Sinclair, Вы писали:


S>Я не очень понимаю, что называется "полноценным дуплексом",


помимо того что для того чтобы послать очередной запрос на сервер ничего ждать ненужно...но и
это когда...информация клиену передается сразу, как только на сервере становиться доступной для передачи.
и не факт, что ответ на какой либо запрос будет передан сразу целиком.
часто быстрее ответы передать кусками (пакетами) от разных запросов и собрать их на клиенте.
Re[9]: Протокол HTTP
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.04.08 03:54
Оценка:
Здравствуйте, Shabi, Вы писали:
S>помимо того что для того чтобы послать очередной запрос на сервер ничего ждать ненужно...но и
S>это когда...информация клиену передается сразу, как только на сервере становиться доступной для передачи.
Гм. Во всех известных мне протоколах информация клиенту передается сразу, как только становится доступной для передачи. Если не включать явную буферизацию.
S>и не факт, что ответ на какой либо запрос будет передан сразу целиком.
Ага, не факт. Читать про стек протоколов, про IP-пакеты и Ethernet-датаграммы.
S>часто быстрее ответы передать кусками (пакетами) от разных запросов и собрать их на клиенте.
Ага. Вот только к слову "дуплекс" это никакого отношения не имеет. "Алиса, никогда не употребляй слова только за то, что они длинные и красивые" (с).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Протокол HTTP
От: Pavel Dvorkin Россия  
Дата: 09.04.08 05:44
Оценка:
Здравствуйте, netch80, Вы писали:


N>А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?


Благородный дон действительно считает эту разницу маловажной по сравнению с задачей написания собственно приложения. Поскольку ввод/вывод в десктопном приложении обычно представляет собой 1% от задачи или около того.
With best regards
Pavel Dvorkin
Re[9]: Протокол HTTP
От: Pavel Dvorkin Россия  
Дата: 09.04.08 05:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму


AVK>Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п.


Господи! Уж банальный дескриптор превратился в проблему!

>Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.


Я вроде в этом разделе ни о каких реальных требованиях не говорил.
With best regards
Pavel Dvorkin
Re[7]: Протокол HTTP
От: Shabi  
Дата: 09.04.08 08:01
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>Бинарность/небинарность с точки зрения оптимизации отходят на второй план. За исключением тех случаев, когда вышеописанные возможности исчерпаны, а результаты не устраивают.


самое интересное происходит в момент преобразование полученной информации в вид пригодный для програмной обработки...и обратно — сериализация...

парсрование бинарного протокола намного проще, а смое главное эффективнее (память, CPU...). что в контексте сервера особливо важно.

(неужели даже с этим найдуца несогласные....)
Re[8]: Протокол HTTP
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.04.08 08:33
Оценка:
Здравствуйте, Shabi, Вы писали:

S>парсрование бинарного протокола намного проще, а смое главное эффективнее (память, CPU...). что в контексте сервера особливо важно.

S>(неужели даже с этим найдуца несогласные....)
1. Ты не мог бы постараться писать на русском языке?
2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста. Даже с учетом RFC 2047.
3. Еще раз поясняю для тех кто в танке: нас мало интересуют накладные расходы на сериализацию/десериализацию. В большинстве случаев они пренебрежимо малы по сравнению с расходами на пересылку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Протокол HTTP
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.04.08 09:10
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, netch80, Вы писали:



N>>А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?


PD>Благородный дон действительно считает эту разницу маловажной по сравнению с задачей написания собственно приложения. Поскольку ввод/вывод в десктопном приложении обычно представляет собой 1% от задачи или около того.


Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально.
The God is real, unless declared integer.
Re[10]: Протокол HTTP
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.04.08 09:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

AVK>>Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п.


PD>Господи! Уж банальный дескриптор превратился в проблему!


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

>>Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.


PD>Я вроде в этом разделе ни о каких реальных требованиях не говорил.


Они подразумеваются.
... << RSDN@Home 1.2.0 alpha 4 rev. 1079>>
AVK Blog
Re[6]: Протокол HTTP
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.04.08 09:57
Оценка:
Здравствуйте, Shabi, Вы писали:

И>>>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.

S>>>....попробуй объяснить загадку природы TCP/IP. :xz: как бы бинарный и о таких проблеммах не слышал
C>>А функции типа htons/htonl видел?l
S>не поленись перечитай то о чё писал я ....
S>(на всякий случай разжевываю. САМ протокол TCP/IP о проблеммах little/big endian НИЧЕГО незнает. ибо конкретно на этом уровне принято одно решение для всех. а вот на уровне приложения.... )

Вы можете "разжёвывать" сейчас сколько угодно, но Ваше предыдущее утверждение, что бинарный TCP/IP избавляет от различий платформ, мягко говоря, некорректно. Охотно верю, что сейчас Вы бы выразились иначе. Но как бы это ни было выражено, это будет методически неправильно: протокол (формат) ни от чего не избавляет. Он может от них уходить или разрешением нескольких вариантов с возможностью однозначно детекта (как делают с юникодными UTF*), или разрешением только одного варианта (как большинство сетевых).

И>>>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук.

S>>>когда ты последний раз отлаживал TCP/IP?
C>>Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня.
S>тоже иногда занимаюсь отлаживанием протоколов (чаще бинарных)....да мои отладчики несколько сложнее, чем примитивный notepad. но как то грусти совершенно никакой нет.

Ну вот расскажите, сколько наворотов нужно сделать в "отладчике" чтобы разобрать протокол.
The God is real, unless declared integer.
Re[9]: Протокол HTTP
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.04.08 10:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста.


ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Протокол HTTP
От: WFrag США  
Дата: 09.04.08 10:18
Оценка:
Здравствуйте, eao197, Вы писали:

E>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.


А как там с расширяемостью?
Re[11]: Протокол HTTP
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.04.08 10:26
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, eao197, Вы писали:


E>>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.


WF>А как там с расширяемостью?


Замечательно. В самой ASN.1 нотации присутствует способ определить специальные точки, в которых структура данных может быть расширена в будущем. Например:
Order-for-stock ::= SEQUENCE
  {order-no     INTEGER,
   name-address BranchIdentification,
   details      SEQUENCE OF
                SEQUENCE
                {item OBJECT IDENTIFIER,
                 cases INTEGER},
   urgency      ENUMERATED
                {tomorrow(0),
                 three-day(1),
                 week(2), ... } DEFAULT week,
   ... ,
   ... ,
   authenticator Security-Type}

(источник: ASN.1 Complete by Prof John Larmouth)
Здесь ... обозначают точки расширения.

Конечно, эти точки расставлять должен разработчик. Так что влияние человеческого фактора здесь может оказаться отрицательным.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Протокол HTTP
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.04.08 10:48
Оценка:
Здравствуйте, eao197, Вы писали:

E>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.

Ты не поверишь, программисту, использующему XML, обычно тоже не приходится этим заниматься вообще. Потому, что используются специальные компиляторы, которые генерируют код сериализации/десериализации по описанию структур.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Протокол HTTP
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.04.08 10:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:


E>>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.

S>Ты не поверишь, программисту, использующему XML, обычно тоже не приходится этим заниматься вообще. Потому, что используются специальные компиляторы, которые генерируют код сериализации/десериализации по описанию структур.

Поверю. Но ведь ASN.1 противопоставлялся не XML, а HTTP:

Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста. Даже с учетом RFC 2047.


Есть ли такие компиляторы для HTTP?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.