Open Source - контест лог под Линукс

**RN9RQ** · 02.04.2009, 17:08

Сообщение от EW1CK

В принципе, если поддерживать режим малти-малти, то клиент-сервер без вариантов. Причем, если пойти до конца и принять во внимание обеспечение простоты инсталляции и делать максимально тонкого клиента, то прихожу к выводу что самым разумным было бы в таком случае ajax/web приложение. Деплоить ничего на клиентов не нужно, вся обработка на сервере. Одинаково легко работают хоть 10 операторов.

Добавлено через 13 минут

Да, причем, если к hamlib у меня нареканий нет, то вот с cwdaemon не все так хорошо. А вернее даже плохо. Управление портом производится полностью процессом, находящимся в пространтве пользователя, а значит о ни о какой более или менее реалтаймовой обработке не может идти и речи и любой своп процесс может портить передаваемый сигнал особенно на высоких скоростях. Что и происходит собственно, хоть и не часто. Это не проблема Линукса, в винде то же самое.
Но в Линуксе это решить проще, нужено написать соответствующий драйвер, который бы работал с cwdaemon но при работе через драйвер, все формирование посылок и отсчет временных интервалов бы реализовывались в пространстве ядра и соответственно сигнал бы был 100% качественным, как в TRLOG

Ну веб вариант не знаю, все же могут быть приличные задержки.
а по cwdaemon не пробовали ему повысить приоритет? Вплоть до realtime ?

**US6IQ** · 02.04.2009, 22:09

Сообщение от RN9RQ

а зачем субсервер, если от сети отпал то работать нельзя

Ага, вы это кому-то другому скажите, мне лично в кантесте нечего больше делать, как искать где и почему у меня заглючила сеть. Надо QSO колбасить, все остальное вторично. Нет сервера - нужно работать, потом до кучи соберем....

**RN9RQ** · 02.04.2009, 22:35

Сообщение от US7IQZ

Ага, вы это кому-то другому скажите, мне лично в кантесте нечего больше делать, как искать где и почему у меня заглючила сеть. Надо QSO колбасить, все остальное вторично. Нет сервера - нужно работать, потом до кучи соберем....

с этим согласен

Добавлено через 2 минуты
только зачем его все время держать, надо запускать локальный сервер в тот момент когда основнйо не доступен

Добавлено через 5 минут
только зачем его все время держать, надо запускать локальный сервер в тот момент когда основнйо не доступен

**RX1AL** · 02.04.2009, 22:52

Завтра выложу документ vision statement для обсуждения. Сегодня не все мысли успел оформить, есть кое-что, что надо додумать.
Но кое-что выскажу сейчас:

1. Архитектура 100% только клиент-сервер. Без вариантов. При этом в случае работы одного оператора, всё рaботает на одном компьютере. В случае мульти-мульти или других сценариев, есть несколько вариантов установки и настройки.
2. Сетевая архитектура P2P. Более продвинутая для нашей задачи контестового лога. Сегодня была успешно протестирована на базе университета.
В случае P2P мы имеем возможность контролировать любого клиента без участия сервера вообще.
3. Для сетевой архитектуры необходимо иметь возможность поддерживать альтернативные способы поддержания работоспособности сети, чтобы учесть различные "катаклизмы" во время контеста. Например, Wi-Fi, кросс-коннект, тот же Bluetooth и другие. Резервный канал нужен по-любому.
4. Только не web архитектура. Иначе нам действительно в случае проблем надо будет "тушить свет" в контесте. Тонкий клиент, да, но не до такой степени.
5. Конфирурацию клиента стоит хранить либо в базе (создается профиль), либо в XML. Редактор удобный для работы с конфигурационным файлом и пользовательскими секциями пишется быстро стандартными средствами. Плюсов полно, задача грамотно написать схему XSD, DTD - тут нас спасает могучая Altova или другой редактор XML схем, коих куча.

CW демона тоже не советую использовать, тут уже правильно сказали, есть проблемы. Писать свои дрова под Линукс - не стоит... Лучше написать свой модуль, а не демон, причем для каждого клиента и запускать параллельным процессом.

ПС Именно потому, что нам надо "колбасить" связи, нам нужна база, как на сервере - так и на стороне каждого клиента. И затем синхронизировать базы, даже в оффлайне, после контеста. Стандартное решение для этого есть, называется occasionally connected clients, или оффлайн/онлайн синхронизация баз данных.

**RN9RQ** · 02.04.2009, 23:08

я не согласен с подходом.
2. п2п смысла нет, наоборот минимальная нагрузка на клиенты.
3. это должно решаться на уровне настройки системы а не лога.
5. С этим так же не согласен, это модное извращение.
6. Необходимость базы так и не доказана, но все упорно её суют.
Спорить похоже бесполезно. Да и не люблю я споры, а тянуть уздечку в сторону от основной массы разработчиков мне накладно.
В общем я умываю руки, от души желаю развития проекту, хотя сомневаюсь, что при таких вводных будут интересные результаты.
В общем всем 73 SK .

**RX1AL** · 02.04.2009, 23:53

Роман, да погоди ты уходить... Никто не спорит, вырабатываем концепцию. Нет еще никаких вводных. Есть только мысли вслух. Вот когда застолбим, тогда и будет, чего сказать. Еще ничего нет, а он уходить собрался. Здорово...
По поводу использования XML - это не моднaя штучка, а необходимость, да и де-факто стандарт. Отрицать его глупо. Ну не делать же на допотопных ini файлах всю конфигурацию? Тут как раз замучаешься и с парсингом и валидацией и значений и переменных.

Необходимость базы доказана. На файловой системе не возможно реализовать транзакции и конкуррентные соединения, т.е. одновременный доступ.
Кроме того, если делать merge по файлам затем, то небходимо иметь diff, что не так легко делается, тем более по всем полям структуры, которую мы определим. В базе, без проблем.

**RN9RQ** · 03.04.2009, 00:10

RX1AL
вы в ручную сколько xml конфигов правили?
зайдите в /etc / и смотрите сколько вы там таких конфигов найдете.
Одновременный доступ к информации не нукжен...

**RX1AL** · 03.04.2009, 01:28

Роман, вручную никто не предлагает править конфигурационные файлы в XML формате. Существуют редакторы для этого. Тот же GRUB, Oxygen XML Editor, Icecast2. Я пользуюсь обычно двумя: GRUB и GConf. Очень удобно. Написать аналогичный для конфигурирования контеста не проблема.

Далее, ты пишешь - "одновременный доступ" не нужен. Поясни, тогда, как ты собираешься избежать коллизий в этом случае? Мы же данные о связи пишем в файл... И что будет, если с двух ранов будет произведена попытка записи? Как решать, опять блокировки реализовывать? Неудобно. Если каждому клиенту в свой файл писать, ок, можно... но как потом объединять файлы?

Приведи тогда четкие аргументы в пользу файловой системы по сравнению с базой данныx. Лучше в виде таблички. В любом случае для нашего первого дoкумента о концепции очень полезно. Кстати по другим вопросам тоже. Я именно так сейчас и делаю, сравнивая разные варианты по плюсам и минусам.

**R8TX** · 03.04.2009, 09:11

Сообщение от RX1AL

Роман, вручную никто не предлагает править конфигурационные файлы в XML формате.

Ясное дело должен быть общий конфигуратор типа N1MM-овского, плюс локальные конфигураторы внутри каждого окна. А уж в каком виде хранятся настройки внутри дело программы дело десятое. Пользователь включает программу чтобы работать в тесте, а не лазить по конфигам.

**UD2F** · 03.04.2009, 09:29

Сообщение от RX9TX

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

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...
(при всем моем уважением к n6tr)

**R8TX** · 03.04.2009, 10:25

Сообщение от RU2FM

Вот еще один ПРЕКРАСНО обоснованный довод в отказе дальнейшего развития tlf...

Кстати у xTLF нормальный графический интерфейс и конфигуратор. Может было бы проще просто форкнуть xTLF?

**RN9RQ** · 03.04.2009, 21:42

Я, признаться, думал, что среди хамов есть нормальные программисты, котрые не пишут быдлокод...
Не удивлюсь если вообще решитена Яве или Моно писать.
Как я разочаровался.
Все, более в эту тему ни ногой.

**RX4HX** · 03.04.2009, 22:25

Сообщение от RN9RQ

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

Родной, а тебе не кажется что ты от своей наглости ох....? Ты в свои 21 сделай сначала что то сделай, а потом других хай!
По простому: я тут много с кем ругался, но люди дело говорили. А ты обсирашь , сам ничего не сделая!

**RN6LIQ** · 03.04.2009, 23:54

Сообщение от RN9RQ

Я, признаться, думал, что среди хамов есть нормальные программисты, котрые не пишут быдлокод...
Не удивлюсь если вообще решитена Яве или Моно писать.
Как я разочаровался.
Все, более в эту тему ни ногой.

Не вдаваясь в то по какому поводу была написана эта фраза, хочу высказаться.
На самом деле мы очень непохожи друг на друга. Договорится, это очень большая проблема. Поэтому когда мы встречаем единомышленника - это праздник жизни. Не ждите понимания. Его скорее всего не будет. А если Вы оригинален, то найти единомышленников большая редкость. Доказать что то свое можно только написав что то свое (программу, речь идет о программировании). Когда оно заработает, и люди это признают, значит это то что нужно. (мнение индивидуалиста

)

**ES1BA** · 04.04.2009, 00:46

Сообщение от RN9RQ

Как я разочаровался.

Молодой человек, у тебя еще ВСЁ впереди... рановато будет...
Давно слежу за постами (сам к програмированию отношения не имею)... сначала было удивление (интерес ?! Какая у нас молодежь!), потом недоумение... дальше... не, дальше не буду.