Высоконадежный копировщик сделок/сигналов (обсуждение идеологии и разработка) - страница 3

Да нифига вот, проблема добавить в сообщение 5-16-32-64 символа ключа ??? где же тут раздув размера сообщения. вы больше потеряете на хендлах для нескольких мессджей чем это.

Ессно что клиент должен отрапортовать, иначе принимаются меры...

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

может все таки создание сокетных постоянных соединений будет более экономично в плане трафика?

Ок давайте тогда всю широту вопросов сузим пока к этим.

- удаленная синхронизация (данные лежат на серваке (в каком виде))
- что отдавать клиенту (последний сигнал или всю совокупность ордеров для синхронизации)

-и метод обмена информацией (что выигрывает в соотношении надежность/экономия ресурсов чистый сокет c прямой связью на клиента или http/ftp с постоянной долбежкой сервера)

А вообще каким языком ограничиваемся?

пока никаким. рассуждаем про идеальный надежный копир

1) однозначно база данных (Мускул)

2) ХТТП или даже ХТТПС - тут надежность и безопасность все таки на первом месте. Трафик - когда 90% народа сидит на унлимите, думаю не смысла обсуждать

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

Идеальный надёжный копир это терминал МТ, тысячи клиентов на один сервер и при этом этой системе доверены миллиона баксов.

Экспуатационные наработки годами, сотни компаний купивших сервак МТ.

Возьми себе сервак МТ и транслируй своим терминалам любой сигнал.

хттп шный доступ хорош еще и тем что при небольших ресурсах сервака можно обслужить большое количество клиентов одновременно.