Разумно ли писать серверное приложение на C # в моем случае?

Question

• Я хочу, чтобы он работал на серверах Windows.
• Это будет сервер облачного типа - он будет состоять из модулей \ частей, работающих на разных машинах по всему миру, использующих http \ tcp + upnp для соединения друг с другом
• На каждой машине будут контролироваться \ модули мониторинга \ наблюдения для обеспечения статистики производительности
• Эта сеть будет работать с большим количеством потоковых \ ВИДЕО / АУДИО потоковых данных \ 1008 *
• Он будет использовать FFMPEG для перекодирования, а OpenGL, OpenCV и т. Д. Для фильтрации (.NET-оболочки существуют и работают BTW)
• Он не будет использовать WCF или IIS
• Я хочу развивать его в команде из 2-4 разработчиков, умных студентов.

Так нормально ли создавать это в C # .Net, или я не буду тратить свое время на обещания легкости, которые он может предоставить разработчику и перейти на C \ C ++?

Так разумно ли в моем случае написать серверное приложение на C #?

---

Оффтоп - почему не WCF

Предупреждение: здесь становится субъективным.

WCF будет полезен, если у вас есть большой корпус с относительно небольшим обменом данными за один сеанс обслуживания.

Когда у вас есть видео, LIVE видео, все становится сложным. Большие объемы данных, большое количество пользователей одновременно входят и выходят из вашего сервиса.

Попробуйте сделать потоковую передачу видео через HTTP-привязку - чем попробуйте другие, чем вы поймете, почему мне не нравится идея прямой трансляции с WCF - это медленно, так как way2much не требуется для информации о прямой трансляции и в конце концов Вы когда-нибудь видели приложение для потокового видео на WCF? Нет - вы не ... возможно, вы видели + - живое видео на паре Silverlight + IIS, которое мне не нравится, потому что оно предназначено только для решения потоковой передачи видео Silverlight \ WindowsMediaPlayer, хотя я хочу большего.

Мне нравится иметь кроссплатформенные клиенты с доступным пользовательским интерфейсом. И мне не нравится (это все тут мое личное мнение - поэтому оно субъективно) Silverlight + IIS + WCF group. Итак, что мне делать - правильно переходить к сокетам, потокам в таких старых и простых форматах, как FLV и Flash, в качестве внутреннего клиента - в некоторых частях проще в разработке, более консервативный способ создания живого видео через Интернет, чем тот, который вы получаете от MS сегодня.

Мне нравится потоковое вещание FLV в реальном времени, потому что вы просто открываете сокет и начинаете отправлять на него живые видеоданные FLV (для каждого FLV-заголовка пользователя, а затем для тега FLV по одному: тег видео, аудио тег, тег видео, аудио и т. д.), и Flash проигрывает его! Без специального \ необычного кода. Он быстрый, легкий в поддержке и не заставляет клиента ничего нового \ необычного. И вы на стороне сервера можете использовать эту «TAG» форму представления видео / аудио данных.

Вот вкратце, поэтому я просто не хочу использовать WCF - сложно получить живое видео, воспроизводимое из него на стороне клиента, никаких общих преимуществ для живого видеосервера.

И когда большая часть живых данных проходит через сокеты, зачем беспокоиться об использовании WCF для управления сервисами.

В течение последней половины 2009 года и первой половины 2010 года я увлекался WCF, потоковым видео в реальном времени, silverlight и flash, сравнивая процесс создания клиента и сервера, читая различные форматы с командой настороженно интересных разработчиков. В общем, в конце проекта у нас было много мини-серверов, транслирующих живые данные, и множество разных клиентов, получающих их. Сравнивая все, что мы сделали, мы пришли к выводам, которые близки к тому, который я вам представляю.

Именно поэтому я не хочу использовать WCF в своем ближайшем проекте - я не хочу думать о том, как доставлять медиаданные, я хочу сосредоточиться на их фильтрации \ редактировании.

---

Почему возник вопрос

Мы начали играть с FFmpeg \ OpenCV в C, и довольно просто манипулировать данными, используя их ... в C ... в Linux ...

Но когда мы начали играть с привязками .Net (сейчас мы играем с Tao.FFmpeg), мы обнаружили, что в большинстве случаев мы много играем с C # Marshal и имеем 2 переменные для его аналога C (проблема указатели) и тд. Я надеюсь, что мы не увидим такой проблемы с Emgu CV, но это меня немного пугает ...

Answer 1

Я думаю, что это вполне разумно.Преимущества C # в отношении простоты разработки значительно перевесят любые недостатки производительности, связанные с отсутствием C ++.

C # обычно более кроссплатформенный, чем C ++.Да, C ++ - это кроссплатформенный язык, но между API, которые программы C ++ используют для взаимодействия с системой, есть большие различия.C # и .Net / Mono имеют гораздо более стандартизированный интерфейс для уровня сокетов.

Наконец, при таких амбициозных проектах, как приведение проекта в удобную форму, гораздо более важная цель, чем достижение максимально возможной производительности,Производительность имеет значение только в том случае, если проект завершен.Запишите это на C #, потому что это даст вам самые большие шансы на завершение.Тогда беспокойтесь о производительности.

Answer 2

Зачем останавливаться на C #, если вы (возможно) хотите кросс-платформенный, напишите его на Python или подобном, вы обнаружите, что сетевые аспекты языка сценариев намного лучше, чем C # (так как это в значительной степени роль сценариев роли)в наши дни языки работают на веб-серверах.

Вы обнаружите, что производительность труда разработчиков значительно выше по сравнению с C # (так же, как C # имеет лучшую производительность по сравнению с C ++), и есть много людей, которые знают ихочу работать на этих системах.Похоже, что производительность самих серверов имеет меньшее значение, чем работа в сети, поэтому кажется, что сценарий будет вашим лучшим выбором.Плюс библиотеки ffmpeg более тесно интегрированы с python, используя pyffmpeg, чем C # (ну, в основном).

И это было бы намного круче, веселее и кроссплатформенно!

Answer 3

Я не совсем уверен, почему люди высказывают озабоченность по поводу кросс-платформенности, поскольку ОП явно заявил, что приложение будет работать в Windows.

Что касается актуальных вопросов.

1. Можете ли вы создать серверное приложение, которое взаимодействует через tcp / http в C #, которое не должно работать в IIS.-> Да.
2. Можете ли вы создать серверное приложение с высокой производительностью и масштабированием в C # -> Да.
3. Можете ли вы сделать это со студентами -> Возможно.Зависит от студентов ...;) Но это не зависит от используемого языка.

Это то, что я хотел бы сделать?Да.Мы сделали это.На данный момент у нас есть приложение ac #, работающее примерно на 20000 компьютерах, которые эффективно взаимодействуют через tcp.Мы не используем WCF, но мы решили использовать службы стиля RESTful через http для передачи данных.

Нашей самой большой проблемой была простая настройка приложения для передачи «правильного» объема данных по проводнойвремя.Эта сеть предназначена для сбора и хранения данных.Это в среднем около 200 ГБ данных, собираемых в день.

ОБНОВЛЕНИЕ
Я хотел бы немного разъяснить о вышеупомянутом приложении.20 000 компьютеров в вышеупомянутой установке являются клиентами (XP, Vista, 7, 2003 Server и 2008 Server).В миксе есть только один сервер точки сбора данных.Клиенты отправляют данные на сервер при подключении к сети один раз каждые 45 секунд.Примерно 97% машин остаются подключенными таким образом, остальные подключаются пару раз в неделю.

Это позволяет серверу обрабатывать около 37 миллионов запросов в день.

Теперь, конечно, каждый запрос является относительно небольшим - от 5 до 6 КБ каждый.Тем не менее, общее количество запросов показывает, что приложение C # может обрабатывать управление этими соединениями, что является большей частью проблемы OP.

Поскольку файлы OP большие (видео), то настоящая проблема заключается простов передаче данных.Что будет больше сдерживаться скоростью жесткого диска, а также скоростью и задержкой в ​​сети.Эти проблемы не зависят от того, на каком языке вы работаете, и будут ограничивать количество соединений на сервер в зависимости от доступной пропускной способности.

Работая над этим, давайте ограничимся одним сервером для примера.Если у вас скорость видео 400 кбит / с и 25 МБ подключение к Интернету, то этот блок может обрабатывать только около 62 одновременных подключений.Это на порядок ниже количества подключений, которые выполняет наше приложение, что является ошибкой округления.

При условии идеальных условий сети (которых не существует), накачка этого подключения к Интернету до 100 МБ (что может быть дорого)) означает 4-кратное увеличение одновременных подключений до 240;все еще полностью управляемый.

Однако сеть - это только одна сторона уравнения.Скорость дисков на серверах имеет большое значение.Лучше иметь хороший дисковый массив, способный непрерывно доставлять такой объем данных.Я знаю, что диски требуют 3 ГБ передачи данных, но диск, который может насытить канал, так и не был создан.Это означает серьезное планирование и деньги при настройке сервера.

Смысл всего этого в том, чтобы сказать, что язык не имеет значения в вашей ситуации.У вас есть другие гораздо более серьезные проблемы.В таком случае используйте язык, который поможет вам быстрее выполнить проект.

Answer 4

Если вам нужен C #, а также кроссплатформенные возможности, ваша разработка должна быть нацелена на платформу Mono (или другую кроссплатформенную среду выполнения .NET, если вы можете ее найти).Возможно, вам придется отказаться от VisualStudio и, возможно, некоторых специфических для Microsoft библиотек и инструментов, но вы все равно можете использовать C # на нескольких платформах.Просто убедитесь, что вы запускаете многоплатформенную сборку и тестируете EARLY в процессе, иначе будет непросто что-то изменить позже.

Answer 5

Если целью приложения является запуск только на платформах Windows, я полностью уверен, что напишу это приложение на C #. Многие подобные приложения могут быть запущены прямо сейчас, и мы даже не знаем этого.

Если целью является запуск на нескольких платформах, вы должны сначала инкапсулировать все проблемы, которые не-Windows-платформа может принести вашему приложению.

Почему вы должны писать это на C ++, если в этом случае C # способен делать все, что делает C ++? Я бы использовал C ++ для программирования вещей на аппаратном уровне, таких как робот или что-то еще. Чтобы написать серверное приложение, C # будет очень хорошо соответствовать тому, что вы хотите, оно было разработано для этих целей.

А C # является кроссплатформенным, вам просто нужен правильный инструмент, чтобы он работал на конкретной платформе.