Бывает, что при отправке множества GET или POST запросов, ответы на них приходят не в том порядке.
Например, если отправили 2 GET запроса, то сначала может прийти ответ на второй, а потом на первый.
Актуально для высоконагруженных серверов, проектов.
Это может быть вызвано настройкой/загрузкой стороннего сервера, загруженностью сети и прочими не зависящими от нас вещами. Мы сделали что смогли - отправили запрос. А дальше уже от нас ничего не зависит.
Вопрос такой - можно ли как нибудь, сформировав GET или POST запрос особенным образом, в ответе точно узнать на какой запрос этот ответ?
Актуально для высоконагруженных серверов, проектов.
Актуально для любых.
Тебе еще рано говорить об высоконагруженных, если ты таких элементарных вещей не понимаешь.
Если у тебя сервер тормозит от смешных 1000 посетителей - то это не проект высоконагруженный, а ты не умеешь готовить ПО.
Это может быть вызвано настройкой/загрузкой стороннего сервера, загруженностью сети и прочими не зависящими от нас вещами.
Это особенности прохождения по сети, как правило - даже в низкозагруженных.
В высокозагруженных с параллельной обработкой к непредсказуемости сети добавляется непредсказуемость на сервере, да.
Я один не понял о чем речь?
Если вы делаете запрос, то в любом случае получите ответ. Если не дождавшись ответа в разорвете соединение, то и ответ никогда до вас не дойдет. это про http.
в js вы всегда в коллбеке получите ответ на нужный запрос
в php file_get_contents сделает запрос и получит ответ сама, вам только вернет результат. в php curl то же самое.
Запрос тут не причём. Вы отправляете запрос и получаете ответ. Если вы отправляете параллельный запрос, синхронизируйте код вашего приложения, а не интернет протоколы, они работают правильно.
P. S.
На всякий случай поясню, что запрос-ответ неразделимы. Не может прийти ответ на другой get/post запрос на прикладном уровне.
Сомневаюсь. Два запроса к удаленному серверу. На том сервере блокировка, при максимальном числе запросов. Результат - на первый запрос получаю второй ответ.
Griboks, Это называется маршрутизация. Если я не ошибаюсь маршрутизатор составляет таблицу соответствия серых и белых ip. Да на том же вконтакте может сидеть целый офис через 1 маршрутизатор, но что куда и кому решает он. Как он там запоминает - я уже не помню.
Griboks, у маршрутизатора есть. Чаще один на всех его клиентов, один белый на 1000 серых (и это не про Гендальфа).
Он выдается/назначается провайдером и бывает как статический, так и динамический. Что не суть.
И да без белого айпи не войти в интернет т.к. непонятно кому отсылать данные из глобальной сети.
Адреса то нет.
Можно, конечно, самому назначить айпи (просто прописав в настройках подключения) и подключится к магистрали (даже не знаю как). "Сказать" - я сам себе назначил белый айпи, привет мир!
И скорее всего это вызовет конфликт сетевых адресов.
А организацией и выдачей белых (или внешнесетевых на языке тру админов) занимается IANA.
Я админ в прошлом...
Евгений Иванов,
в js вы всегда в коллбеке получите ответ на нужный запрос
в php file_get_contents сделает запрос и получит ответ сама, вам только вернет результат. в php curl то же самое.
- не уверен что так будет.
При обычных запросах - да. А вот когда есть высоконагруженные серверы, которые тормозят, загруженные каналы, куча межсетевых экранов - тогда кто его знает. Конкретно на php не тестировал.
На с++ возникает именно такая ситуация. При частых запросах и проблемах на той стороне.
Андрей Буров,
веб-морда по определению не должна слать столь частые запросы, в разрезе одной пользовательской сессии.
пользователь так быстро не способен генерировать события.
если веб-морда шлет чаще, чем минимальное разрешение таймера - где-то что то у вас не так сделано.
при совпадении timestamp - откладывать запрос на подходящую под задачу долю секунды. а лучше все таки найти эту багу.
Господа. Не важно таймстемп или другая метка. Уникальность метки - не вопрос.
Вопрос в том, как её отправить и получить с ней ответ?
Отправить то можно, например так microsoft.com/api?get_data&metka=zapros1
Но назад она, вроде, не вернется т.к. ответ от сервера формирует сервер. А он не мой.
