Так из вашего поста требования не понятны - сколько надо IP сейчас и в перспективе, должны ли они быть из разных сетей и насколько разных, потребуется ли расширения, в какие тайминги надо уложиться, где находитесь вы и где биржа, какие реально нагрузики по RPS ожидаются. От этого зависит или взять свое железо с многими IP но из близких сетей либо пользоваться услугами прокси с многими исходящими адресами. Если нужны гарантированные тайминги и они должны быть минимальны - то делить железо с кем-то нельзя и надо поднимать все на своем железе, VPS/VDS не подойдут, надо брать нормальный колокейшн и находиться он должен либо рядом с вами, либо рядом с биржей либо по пути трафика между вами и биржей. Если у вас допустимо +- 100 миллисекунд, то особо беспокоиться вообще не о чем, вам практически любое стабильное решение подойдет (кроме бесплатных проксей и проксей через ботнеты).
beduin01, а что имеется ввиду под структурой объектного кода? Формат файла объектного кода обычно или тот же что и у исполняемого файла (ELF для Linux), или очень похожий (COFF для Windows).
beduin01, в объектном коде есть информация об именах, типах функций и переменных и их расположении, таблицы импорта и экспорта для статической линковки, все это и информация о том, что в каком объектном файле располагалось при статической линковке полностью или частично теряется и получить обратно можно только путем анализа и то не полностью.
Mercury13, в Windows хидер-файлы можно не конвертировать, если есть стаб. Стаб линкуется как статическая библиотека, вызывается статическая функция, которая уже сама дергает соответствующую динамическую.
В Linux все еще интересней, там все глобальные символы по-умолчанию являются экспортируемыми/импортируемыми, т.е. в хидер-файлах ничего вообще менять не требуется.
P.S.
> К примеру влинковать в бинарик функции из динамической библиотеки.
вызвать функции из динамической библиотеки легко, имея статическую стаб-библиотеку, которая создается при создании динамической библиотеки.
Если ее нет, и в наличии есть только динамическая библиотека, то это все равно реально, но для каждой фукнции нужно точно знать типы возвращаемого значения, аргументов и соглашения вызовов. В самой динамической библиотеке этой информации может не быть.
beduin01, уже дополнил. Создать из статической библиотеки динамическую не сложно. Обратно проблематично, т.к. требуется декомпиляция исполняемого кода и сбор объектного из декомпилированного.
algotrader2013, да, именно гугл построил собственную инфраструктуру, это даже не CDN а скорее наложенная сеть, где-то там CDN, где-то кэширование, а где-то просто проброс сетевого трафика, снаружи все это можно увидеть только по косвенным признакам. Он самостоятельно организует каналы и заключает договоры в точках обмена трафиком, и это скорее исключение. Часто используются сторонние CDN, например Microsoft использует Akamai и местами Verizon. Тот же Azure для разных задач может использовать и Akamai и Verizon и собственную инфраструктуру Microsoft.
Jorik_Wa, в том то и дело что не увидел слова "авторизация", а должен был бы, т.к. с помощью токенов обычно производится авторизация, а не аутентификация. Т.е. вы два раза использовали слово "аутентификация" не правильно - куки сеансовые, а не аутентификационные, а токен авторизации а не аутентификации.
P.S. Если конечно вы имеете не имеете ввиду аппаратные токены.
Jorik_Wa, у вас формулировка вопроса некорректна, т.к. вы смешиваете аутентификацию, авторизацию и создание сеанса. Если ответ не устраивает - уточните вопрос.
dableproger, почему не используется DNS это отдельный вопрос и я на него ответа знать не могу. SRVFAIL скорей всего происходит потому, что вы не разрешили клиенту делать рекурсивные запросы. Надо либо использовать set norecursion в nslookup, либо разрешить рекурсивные запросы с вашего IP в bind. Если это не поможет - загляните сначала в логи.
Qubc, Не совсем, может отличаться порядок экспорта внешних функций, соглашения об их наименовании, соглашения о вызовах функций, формат call frame.
Код тоже не будет одинаковым и может отличаться в зависимости от компилятора, его версии, применяемых оптимизаций, использованию расширенных инструкций, которые так же могут по умолчанию отличаться в разных системах.
Андрей Буров, в TCP-соединении есть состояние соединения, которое поддерживается через номера последовательностей (sequence number). При этом каждая из сторон подтверждает получение пакета с определенным sequence number используя acknowledgment. Поэтому его не возможно установить в одну сторону, необходим трафик в две стороны. Начальный sequence number генерируются каждой и сторон в ходе трехшагового хенжшейка (3-way handshake) и является уникальным.
При подобном зеркалировании, трафик приходящий от клиента к серверу с точки зрения того сервера, куда вы зеркалите, всегда будет out of order, что приведет к сбросу соединения.
Зеркалировать запросы в данном случае можно только путем установки двух независимых TCP-соединений с разными хостами.
Дмитрий Королев, это о чем вопрос?
По-умолчанию используется буферизующий режим, printf кладет данные в буфер в памяти, fflush() делает write() этих данных из памяти в файловый дискриптор.
Если отключить буферизацию, printf() сразу будет вызывать write().
Дмитрий Королев, все хитрей, это задает не состояние буфера, а режим буферизации входящего потока, состояние буфера скорей всего не меняется. Буфер при этом все равно может быть, он используется для ungetc(), а ungetc() используется в том же scanf(), например scanf("%d",...) оставит символ в буфере даже в небуферизирующем режиме.
У вас, скорей всего, немного неверные ожидания. Вы считаете что буферизация синхронизована с действиями пользователя, а это в общем случае не так и сильно зависит от системы и устройства, которое используется для stdin. stdin это не обязательно консоль и не имеет смысла ждать от него консольного поведения. C не предоставляет стандартных методов работы с консолью, работа с консолью очень сильно системозависима.
