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

**RX1AL** · 01.04.2009, 22:50

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

Да, если номер уже успели передать, то придется подправить, но тем не менее при подобной схеме дубляжей или пропусков не будет.

Работать будет и такой способ синхронизации на lock identity в базе. Но с двумя оговорками: а) в случае потери соединения по сокету - rollback в базе и номер возвращается. Нужен механизм на триггерах, убирающий "дырки" в ней; б) резервирование номера в базе, не есть его commit. В любом случае сначала по insert создается новая пустая строка в базе. При этом identity не увеличена ещё. Когда будет произведена запись в таблицы, произойдет инкремент. И если пользователь нажал escape или ошибка записи - имеем inconsistence. Решаемо конечно всё.

**R8TX** · 01.04.2009, 22:54

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

Поздравляю. Надеюсь и не рухнет. Но перестраховатся стоит.

Забыл добавить, N1MM таки делает бекапы лога во время теста, они кладутся в каталог программы но в каком-то другом формате, как с ними работать я не знаю, поскольку пользоваться этой функциональностью не приходилось. Но даже при полном падении базы лог можно оперативно восстановить. Опен-сорс рулит

**RX1AL** · 01.04.2009, 22:56

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

Элементарная ситуация, первое место на общий вызов работает кого-то с номером 001. В это время 2-ое место на поиске отдает кому 002. Первое место отдает кому-то 003. На 2-ом месте QSO не удается, номер 002 повисает в воздухе. Проблема в принципе не решаемая, поэтому судьи крупных тестов не штрафуют за путаницу с номерами, никто не следит за последовательностью передачи номеров или пропусками в отданных номерах. То есть 1-ое место может после 003 отдать и 002 и 004, никого не накажут. Главное чтобы в общей статистике указывалось число реально проведенных QSO.

Асхат, в том-то и суть, что в случае P2P номер не повисает, так как каждый клиент связан также и другим клиентом. И мультовое место просто отдаст номер напрямую на рабочее место. А потом уже номер с commit transaction летит в базу. Но реализовать P2P на базе Линукса - дело тяжкое. На мелкомягких это решается, средства есть, мы тестировали в универе - работает.

**RA6XTD** · 01.04.2009, 22:57

2 RX1AL
При чем тут блокировка записей, если их физически еще нет?
QSO не состоялось еще. Post не было.
А если делать резервирование но с транзакцией, то ваши изменения по оной не увидит другой клиент, пока вы не закоммитите транзакцию. И не увидев резерва подумает, что номер надо использовать старый. Тут не в ID дело, а в том, что человеку надо на экране уже видеть номер, который ему надо давать.
ИМХО, средствами базы данных вы это не решите.
Вариант Insert'а с последующим Post'ом и потом Delete в случае неудачи - это как-то через одно место.

Так что, опять же имхо, сторонний мини-сервачок, обеспечивающий ЛОГИЧЕСКОЕ распределение номеров это лучший вариант. Единственный у него минус - это если второй клиент со старшим номеров уже сохранил QSO, а второй завис или еще что-нибудь. Вот в этом случае возможна дырка и забив ее время проведения 2-й связи будет больше чем 1-й. Ну о чем и говорил RX9TX.

**RX1AL** · 01.04.2009, 22:58

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

Забыл добавить, N1MM таки делает бекапы лога во время теста, они кладутся в каталог программы но в каком-то другом формате...

Что там за формат для бекапа? Ответ в личку плииз... Я чего-то не нашел у себя...

**RN9RQ** · 01.04.2009, 23:00

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

Элементарная ситуация, первое место на общий вызов работает кого-то с номером 001. В это время 2-ое место на поиске отдает кому 002. Первое место отдает кому-то 003. На 2-ом месте QSO не удается, номер 002 повисает в воздухе. Проблема в принципе не решаемая, поэтому судьи крупных тестов не штрафуют за путаницу с номерами, никто не следит за последовательностью передачи номеров или пропусками в отданных номерах. То есть 1-ое место может после 003 отдать и 002 и 004, никого не накажут. Главное чтобы в общей статистике указывалось число реально проведенных QSO.

Не все так трагично. Есть вариант

**RX1AL** · 01.04.2009, 23:03

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

При чем тут блокировка записей, если их физически еще нет?
QSO не состоялось еще. Post не было.

Так что, опять же имхо, сторонний мини-сервачок, обеспечивающий ЛОГИЧЕСКОЕ распределение номеров это лучший вариант. Единственный у него минус - это если второй клиент со старшим номеров уже сохранил QSO, а второй завис или еще что-нибудь. Вот в этом случае возможна дырка и забив ее время проведения 2-й связи будет больше чем 1-й. Ну о чем и говорил RX9TX.

Теперь понял, о чем вы...

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

**R8TX** · 01.04.2009, 23:05

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

Цитата:
Сообщение от RX9TX Посмотреть сообщение
Элементарная ситуация, первое место на общий вызов работает кого-то с номером 001. В это время 2-ое место на поиске отдает кому 002. Первое место отдает кому-то 003. На 2-ом месте QSO не удается, номер 002 повисает в воздухе. Проблема в принципе не решаемая, поэтому судьи крупных тестов не штрафуют за путаницу с номерами, никто не следит за последовательностью передачи номеров или пропусками в отданных номерах. То есть 1-ое место может после 003 отдать и 002 и 004, никого не накажут. Главное чтобы в общей статистике указывалось число реально проведенных QSO.
Асхат, в том-то и суть, что в случае P2P номер не повисает, так как каждый клиент связан также и другим клиентом. И мультовое место просто отдаст номер напрямую на рабочее место. А потом уже номер с commit transaction летит в базу.

Номер 002 УЖЕ отдан мультовому месту и ПЕРЕДАН корреспонденту, а рановое место УЖЕ провело отдало 001 и 003. ЩСО на мультовом месте не удается, 002 - повисает.

**RA6XTD** · 01.04.2009, 23:06

Нет, RX9TX прав.
Все равно идеального варианта когда связи в логе будут идти 1, 2, 3 и т.д. никогда не добиться. Т.к. как уже было в примере QSO с номером 3 уже сохранено, а QSO с номером 2 - еще нет. Вот уже разнобой и от него НИКУДА НЕ ДЕТЬСЯ.
Тут главное - чтобы не было ДУБЛЯЖА связей. Т.е. чтобы у двух клиентов, запустивших программу с пустым логом и нажавшим New QSO изначально на экране были разные номера.
Подсоединился третий, четвертый - и у них опять же другие номера...
Вот что главное.

**R8TX** · 01.04.2009, 23:08

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

Что там за формат для бекапа? Ответ в личку плииз... Я чего-то не нашел у себя...

Завтра посмотрю.

**RN9RQ** · 01.04.2009, 23:09

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

Добавлено через 2 минуты
Михаил Я все же думал про psp и моно эта такая тонкая шутка...
а сервер просто необходим и будет.

**RA6XTD** · 01.04.2009, 23:14

А насчет архитектуры хранения.
Какие тут могут быть альтернативы базе данных?
А экспортировать можно хоть в кабриллу, хоть в зебриллу - это уже дело десятое.
И Pearl тут каким местом я не пойму.
Тут всего 2 составляющие - база данных и взаимодействие между клиентами или клиентами и сервером по сети, т.е. сокеты. Всё.

**RX1AL** · 01.04.2009, 23:14

RA6XTD:
А кто нам мешает завести две sequence или autoincrement? Мысль такая: одна контролирует последовательность номеров по логу, а вторая следит за выдачей и "дырками". Тогда проблема упорядочения решается гораздо проще, чем с одним id только для номера. Но в любом случае, пока - это частные вопросы. Нам надо основное решить.

RX9TX:
Асхат, ок, я понял... жду.

**R8TX** · 01.04.2009, 23:18

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

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

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

**RA6XTD** · 01.04.2009, 23:21

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

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

+1