C# и кроссплатформенность
Приложение из себя представляет многопоточный сервер, расчитанный на одновременную работу с несколькими тысячами клиентовНе рекомендую писать такие сервера на C# или Java.
Если же вопрос выбора не стоит, то в целом, все терпимо. Проблемы будут, но по мелочам. Проявляться будут в разных местах, поэтому для того, чтобы разрабатывать на разные платформы надо иметь как минимум две вещи:
1. build bots, которые при каждом изменении репозитория будут собирать для всех нужных платформ и конфигураций. Как только что-то упало, делать невозможным сабмитить дальше и кричать всем по e-mail, чтобы исправили.
2. unit и integration tests.
Как пример проблем (хотя я не имел большого опыта в кроссплатформенной разработке на шарпе видел различия в поведении в сокетах (скорее всего уже пофиксили) и not implemented на какую-то vista specific строчку в GUI.
Не рекомендую писать такие сервера на C# или Java.Отлично, приведи пожалуйста аргументы в пользу этого. Я сам не взялся доказывать такую точку зрения, так как не обладаю достаточной квалификацией. Человек, который это будет писать раньше писал такое на плюсах, а теперь хочет таким образом поднабраться опыта в шарпе. При этом утверждает, что должно получиться намного быстрее (в плане скорости разработки). Вроде как будет меньше проблем с многопоточностью.
На плюсах сервер имеет примерно такую архитектуру, как я понимаю: есть фиксированное количество потоков (зависящее от числа ядер процессора которые периодически обращаются к неблокирующему сокету за новыми порциями информации, а затем обрабатывают. При этом приходится постоянно задумываться о правильной последовательности лока-разлока ресурсов, дабы избежать дедлока. Человек утверждает, что в шарпе с этим проблем будет меньше.
man epoll
man kqueue
насколько я знаю, мона эти вещи не поддерживает
В таком случае, писать на C# этот сервер под ось с линупсом или *BSD глупо
man kqueue
насколько я знаю, мона эти вещи не поддерживает
В таком случае, писать на C# этот сервер под ось с линупсом или *BSD глупо
Отлично, приведи пожалуйста аргументы в пользу этого. Я сам не взялся доказывать такую точку зрения, так как не обладаю достаточной квалификацией. Человек, который это будет писать раньше писал такое на плюсах, а теперь хочет таким образом поднабраться опыта в шарпе. При этом утверждает, что должно получиться намного быстрее (в плане скорости разработки). Вроде как будет меньше проблем с многопоточностью.полностью поддерживаю. Писать такое на плюсах намного хуже.
Шарп и java проблемы доставят в плане пауз, которые будут получать клиенты в момент, когда идет сборка мусора. Причем, поскольку разумных тулзов, которые умеют залесть в боевой сервер и понять, почему там так загаживается память, нет, то надо иметь ввиду, что рестарт сервера не должен быть разрушительным для ваших клиентов.
Из того, что я мог бы посоветовать для такой системы — это Эрланг (без шуток, на нем довольно много подобных вещей написано, причем, и в России тоже. Как пример: ЖЖ одного такого товарища).
Но наверное, я не буду советовать уж очень активно, поскольку сам Эрланг знаю слишком слабо.
Из того, что я мог бы посоветовать для такой системы — это Эрлангхыхы, забавно, вчера тоже про это читал, правда, другую ссылку
Yaws - веб-сервер на Erlang
Не рекомендую писать такие сервера на C# или Java.А чё, тысячи клиентов - такое в наше время и Visual Basic потянет.
ЖЖ в качестве примера вряд ли удачен, такой тормозной сервис еще поискать надо.
мой трассировщик, запущенный под моно, тормозил в 1.5 раза кажется. хотя вполне могу врать (в смысле не корректно эксперимент ставили)
ЖЖ в качестве примера вряд ли удачен, такой тормозной сервис еще поискать надоя дал ссылку на ЖЖ человека, который пишет на эрланге. Сам движок ЖЖ написан на Перле в основном. Прошу прощения за то, что непонятно выразился.
Красава
Эрланг медленный. Что бы там про него ни говорили, а медленный, собака.
Эрланг используют не для быстрых серверов, а для тучи мелких.
Для поставленной задачи надо не заморачиваться, а разделять задачи
и ставить обратный прокси. Например, хвалёный nginx.
---
Q4: а что за платформа XXX?
A4: на нее кажется вчера или позавчера взгромоздили linux.
Или по крайней мере собираются взгромоздить завтра.
Эрланг используют не для быстрых серверов, а для тучи мелких.
Для поставленной задачи надо не заморачиваться, а разделять задачи
и ставить обратный прокси. Например, хвалёный nginx.
---
Q4: а что за платформа XXX?
A4: на нее кажется вчера или позавчера взгромоздили linux.
Или по крайней мере собираются взгромоздить завтра.
Оставить комментарий
dangerr
Правильно ли я понимаю, что если писать на Visual Studio под последнюю версию .net консольное приложение, то проблем с портированием его в mono и gnu/linux не будет? Если неправильно, то какие могут возникнуть проблемы? И как насчёт производительности? Приложение из себя представляет многопоточный сервер, расчитанный на одновременную работу с несколькими тысячами клиентов и базой данных (mysql скорее всего).