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

Question

• Я хочу, чтобы он работал на серверах Windows.
• Это будет сервер облачного типа - он будет состоять из модулей \ частей, работающих на разных машинах по всему миру, используя http \ tcp + upnp для подключения друг к другу
• Будет осуществляться контроль \ мониторинг \ наблюдения модулей на каждой машине, чтобы обеспечить статистику по производительности
• Эта сеть будет работать с большим объемом данных вещания жизнь потокового \ VIDEO \ AUDIO
• Он собирается использовать FFMPEG для повторного кодирования и OpenGL, OpenCV и такие как фильтрация (.NET-обертки существуют и работают BTW)
• Он не будет использовать WCF или IIS
• Я хочу развить его в команде из 2-4 разработчиков, умных учеников.

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

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

---

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

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

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

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

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

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

Я люблю флеш-трансляцию FLV в прямом эфире, потому что вы просто открываете сокет и отправляете на него живые видеофайлы FLV (для каждого пользователя FLV-заголовка и FLV «TAG», один за другим: тег видео, звуковой тег, тег видео, аудио-тег и т. д.), и 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

Я не совсем уверен, почему люди подняли проблемы с Cross Platform, так как очевидно, что OP заявила, что приложение будет работать в Windows.

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

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

Является ли это чем-то, что я буду делать? Да. Мы это сделали. Сейчас у нас есть приложение C#, работающее примерно на 20 000 машинах, которые эффективно взаимодействуют через tcp.Мы не используем WCF, но мы решили использовать службы стиля RESTful через http для передачи данных.

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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