Comments 28
Автору — спасибо!
Как-раз вовремя. Есть подходящая задача :)
Как-раз вовремя. Есть подходящая задача :)
Это типа ru.wikipedia.org/wiki/ASN.1 + zeroc.com/, только от Facebook?
Подобное решение я делал на php, для работы с hadoop, забавная вещь)
Не понял одного. А как «Почти автоматически получаете клиентов на всех поддерживаемых языках.»? По-моему, вы весь код клиента вручную написали…
Нет, не вручную. Я просто создал экземпляр класса
Для сравнения можно написать этот же клиент вручную с использованием сокетов, и сравнить размер и затраченные усилия.
Ну а потом еще портировать его на остальные языки при необходимости, задумываясь о размерах типов данных, big/little endian и прочем.
TimeService.ClientGetTimeДля сравнения можно написать этот же клиент вручную с использованием сокетов, и сравнить размер и затраченные усилия.
Ну а потом еще портировать его на остальные языки при необходимости, задумываясь о размерах типов данных, big/little endian и прочем.
А можно, ни о чем не думая, даже о том, что может понадобится перейти с сокетов на шаред мемори или http, сделать это на WCF?
Я думаю ниже я ответил и на этот комментарий.
под клиентом тут имелась ввиду реализация
TimeService.Client
Мы использовали эту штуку тут.
правильно ли я понял, что это некоторая альтернатива WCF? Если да, то не могли бы вы описать преимущества Thrift перед WCF? Кроме возможности бесплатно генерировать клиентов на разных языках.
Вот люди мучаются, разрабатывают стандарты, спецификации, протоколы, придумывают всякие SOAP-ы, REST-ы… Но это все не для нас, нам все равно, что под .Net есть WCF, который реализует все это в десятки раз лучше, чем мы когда-либо напишим в ручную…
Нет, мы полезем ковыряться в сокеты, с помощю новомодного инструмента, написанного от безысходности и совсем для другого, и нас не остановит отсутствие документации, нам просто лень прочитать что такое WCF и хорошенько изучить как такие вещи делаются в .Net
=))))
Нет, мы полезем ковыряться в сокеты, с помощю новомодного инструмента, написанного от безысходности и совсем для другого, и нас не остановит отсутствие документации, нам просто лень прочитать что такое WCF и хорошенько изучить как такие вещи делаются в .Net
=))))
Сюрприз! Система может быть написана на нескольких языках.
В данном примере и клиент и сервер на C# поэтому приемущества не очевидны.
Я отлично знаю как работает WCF. Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости. Поэтому рано или поздно вы остаетесь со старыми добрыми сокетами. Редко, но так бывает. Это что касается скорости.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
Можно сказать что Thrift изобрели как раз от безысходности, потому что в Facebook используется куча языков и нужно организовать коммуникацию. Но мне кажется это лучше чем сделать это все через HTTP.
Я отлично знаю как работает WCF. Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости. Поэтому рано или поздно вы остаетесь со старыми добрыми сокетами. Редко, но так бывает. Это что касается скорости.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
Можно сказать что Thrift изобрели как раз от безысходности, потому что в Facebook используется куча языков и нужно организовать коммуникацию. Но мне кажется это лучше чем сделать это все через HTTP.
> Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости.
У WCF нет проблем со скоростью. Транспорт можно выбрать любой, SOAP и REST это только протоколы, как раз и облегчающие кроссплатформенное взаимодействие между сервером и клиентом.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Ага, представил… =)) В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт. А дальше все зависит от того, что это за БД, для каких целей и как будет использоваться — если это общая база, клиенты к которой могут быть где угодно, то REST как раз для этих задач и создавался.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
У WCF нет проблем со скоростью. Транспорт можно выбрать любой, SOAP и REST это только протоколы, как раз и облегчающие кроссплатформенное взаимодействие между сервером и клиентом.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Ага, представил… =)) В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт. А дальше все зависит от того, что это за БД, для каких целей и как будет использоваться — если это общая база, клиенты к которой могут быть где угодно, то REST как раз для этих задач и создавался.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
>У WCF нет проблем со скоростью.
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI. Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
>Транспорт можно выбрать любой, SOAP и REST...
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
>В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт
БД бывают разные, если это in-memory key-value storage и вам надо получить из него по списку ключей данных на 100Мб, то передача данных займет в разы больше времени чем их поиск по словарю в памяти БД.
>То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Это один из сценариев. Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
А вообще это не альтернатива WCF, я ни в коей мере не агитирую всех бросить WCF, REST и прочее и перейти на Thrift, просто поделилися новой (для меня) технологией, может быть у кого то будет сценарий, когда мой пример пригодится.
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI. Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
>Транспорт можно выбрать любой, SOAP и REST...
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
>В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт
БД бывают разные, если это in-memory key-value storage и вам надо получить из него по списку ключей данных на 100Мб, то передача данных займет в разы больше времени чем их поиск по словарю в памяти БД.
>То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Это один из сценариев. Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
А вообще это не альтернатива WCF, я ни в коей мере не агитирую всех бросить WCF, REST и прочее и перейти на Thrift, просто поделилися новой (для меня) технологией, может быть у кого то будет сценарий, когда мой пример пригодится.
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI.
Ого! =)
1. не более простую, а более универсальную. Задача проста — передать данные от одного процесса к другому и обратно, все остальное — транспорт, транзакционность, контракт, прочие условия — детали реализации, которые можно собрать как из кирпичиков под текущую задачу. Это не просто, зато очень гибко.
2. GUI тут вообще не причем, в WCF через GUI не делается ничего :)
Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
Как минимум не отстанет. :) Расходы на сериализацию/десериализацию — минимальны, там весь код эммитится (или LWCG если быть точным, в зависимости от сериализатора), других накладных расходов нет. Чтобы угнаться, придется каждый объект в ручную сериализовать или тоже какой кодогенератор использовать.
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
Так и ваш код тоже будет поверх него. :)
Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
Для доступа из других языков есть стандартые протоколы, зачем еще один?
… может быть у кого то будет сценарий, когда мой пример пригодится.
Вот и хотелось бы понять, что это за сценарии.
Ого! =)
1. не более простую, а более универсальную. Задача проста — передать данные от одного процесса к другому и обратно, все остальное — транспорт, транзакционность, контракт, прочие условия — детали реализации, которые можно собрать как из кирпичиков под текущую задачу. Это не просто, зато очень гибко.
2. GUI тут вообще не причем, в WCF через GUI не делается ничего :)
Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
Как минимум не отстанет. :) Расходы на сериализацию/десериализацию — минимальны, там весь код эммитится (или LWCG если быть точным, в зависимости от сериализатора), других накладных расходов нет. Чтобы угнаться, придется каждый объект в ручную сериализовать или тоже какой кодогенератор использовать.
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
Так и ваш код тоже будет поверх него. :)
Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
Для доступа из других языков есть стандартые протоколы, зачем еще один?
… может быть у кого то будет сценарий, когда мой пример пригодится.
Вот и хотелось бы понять, что это за сценарии.
1. Все дело в том, что WCF создан для решения круга типовых задач. Поэтому всегда будет проигрывать в скорости качественной реализации заточенной под одну конкретную задачу. Плюс WCF в том что все можно сделать проще и с меньшим количеством кода.
2. Ну да, создать классик навесить на него аттрибуты а потом получить готовый клиент через «Add service reference» это конечно ни какого GUI и удобств, а конфигурационные файлики кстати можно править через WCF Service Configuration Editor который есть в студии.
Но неважно как вы создаете сервис через GUI, xml или еще как. Вы пишите на более высоком уровне абстракции, и настоящий код за вас генерят. А сгенерированный код не может быть оптимальным под все задачи, иначе мы бы давно из кирпичиков мышкой весь код собирали.
По этой же причине мой код поверх TCP/IP будет работать быстрее, потому что он заточен под одну конкретную задачу, а не под общий случай.
По поводу приложения, предлагаю вам написать простенькое приложение на WCF, например такой же TimeServer и клиент который запрашивает достаточно много раз время. А затем я перепишу его с использованием сокетов. Замерим и все станет ясно :)
Как вам такой вариант вместо того что бы спорить в теории?
2. Ну да, создать классик навесить на него аттрибуты а потом получить готовый клиент через «Add service reference» это конечно ни какого GUI и удобств, а конфигурационные файлики кстати можно править через WCF Service Configuration Editor который есть в студии.
Но неважно как вы создаете сервис через GUI, xml или еще как. Вы пишите на более высоком уровне абстракции, и настоящий код за вас генерят. А сгенерированный код не может быть оптимальным под все задачи, иначе мы бы давно из кирпичиков мышкой весь код собирали.
По этой же причине мой код поверх TCP/IP будет работать быстрее, потому что он заточен под одну конкретную задачу, а не под общий случай.
По поводу приложения, предлагаю вам написать простенькое приложение на WCF, например такой же TimeServer и клиент который запрашивает достаточно много раз время. А затем я перепишу его с использованием сокетов. Замерим и все станет ясно :)
Как вам такой вариант вместо того что бы спорить в теории?
«это в десятки раз лучше, чем мы когда-либо напишим в ручную…» советую чуть меньше религиозности. коллеги активно слезают с WCF в сторону socketов и protocol buffers. Потому что WCF — м е д л е н н ы й.
UFO just landed and posted this here
Может коллеги просто готовить его не умеют? Со скоростью у WCF все прекрасно, я проверял.
В десятки раз лучше — это не религиозность, я очень хорошо себе представляю во что может обойтись написание клиент-серверного взаимодействия с поддержкой двунаправленности, гарантии доставки, отсутствия дубликатов, смены транспорта, и прочей фигни которая еще может понадобится.
В десятки раз лучше — это не религиозность, я очень хорошо себе представляю во что может обойтись написание клиент-серверного взаимодействия с поддержкой двунаправленности, гарантии доставки, отсутствия дубликатов, смены транспорта, и прочей фигни которая еще может понадобится.
у нас на БД-серверах Cassandra большая часть неприятностей из-за Thrift. Довольно нестабильная технология.
$(SolutionDir)\Thrift\thrift-0.5.0.exe -gen csharp -o $(ProjectDir) $(ProjectDir)\TimeService.thrift
было бы не плохо оформить в codegenerator для custom tool в visual studio.
дело нескольких часов, если найдется доброволец, то вот статья, которая должна помочь www.drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/
было бы не плохо оформить в codegenerator для custom tool в visual studio.
дело нескольких часов, если найдется доброволец, то вот статья, которая должна помочь www.drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/
Sign up to leave a comment.
Использование Thrift в .NET