Судя по access-логу, он этот файл вообще не отдавал о_О Он в логах появился только после перезагрузки, правильного размера. Но до этого браузер его почему-то видел, и Firebug показывал код ответа 200 (то есть файл не из кэша), и IP-адрес правильный.
Я их сравнивал глазами — через браузер и через cat в консоли. Различия бросаются в глаза, между файлами вообще ничего общего. Просто с md5, мне показалось, будет нагляднее.
@throughtheether прошу прощения, писал по конец рабочей смены, в голове был сумбур, в комментарии тоже получилась каша :-) Но, как ни странно, Вы меня поняли и на вопрос ответили. Даже чуть больше, чем я хотел, благодарю.
@opium старая добрая ленька :-) И надежда, что кто-нибудь, прочитавший RFC от корки до корки, снизойдёт до ответа на мой вопрос раньше, чем я осилю RFC или возьмусь за такого рода эксперименты.
FLP - это способ согласовать режим работы (сколько мегабит, сколько дуплексов). По TCP/IP это всё L1, но фактически это ещё ниже. По OSI это будет физический нулевой уровень. Здесь он никак не может свой MAC передать.
Да и узнавать конечному хосту, кто у него в соседях (на уровне L1, при условии что настройки уровня L2 ему уже заданы), ни к чему. Получается, первым пакетом будет либо DHCP, либо уже передача информации. Вывод: сетевой интерфейс с настроенным IP-адресом не передаёт в сеть ничего до отправки первого "содержательного" пакета (ARP можно тоже отнести к содержательным), а значит и коммутатор (фильтрующий мост :-) ) ничего не узнает о новом хосте до этого момента.
А если у интерфейса уже прописан статический IP? ARP, насколько я понял (мог не правильно понять), будет послан уже для того, чтобы послать первый IP-пакет. И именно с этим ARP-ом коммутатор (или как меня тут поправили, фильтрующий мост) узнает MAC свежеподключившегося. Так?
За КПД спасибо. Собственно, из-за него и захотелось поэкспериментировать. Подумалось, почему не делают водонагреватели с магнетроном вместо ТЭНа. Теперь ясно.
Точно, я как раз про парообразование думал. Однако после 4 минут вода была далека от кипения и от перегрева. Градусника со шкалой до 100 градусов у меня нет, но это чувствовалось на ощупь, да и чай в ней толком не заварился. Выходит, у микроволновки КПД ниже, чем у чайника?
@EnterSandman стоит microtime(true) в самой-самой первой строчке скрипта и в самой-самой последней. Разница между ними меньше секунды. Но, тем не менее, сервер думает гораздо дольше. И скорее уж sleep(random()), время ожидания колеблется))))
Именно от Firebug я узнал, что 10 секунд уходит именно на ожидание ответа от сервера. Подключение и получение данных занимает ничтожные микросекунды. Меня интересует, чем занимается сервер между установкой соединения и передачей данных.
Не понятен вопрос. Я использовал оба справочника, но как студент, с помощью официального сайта. Об их устройстве кое-что знаю, могу проконсультировать. Для России — это лучшие справочники, точнее и подробнее нигде не найдете. Хотя они больше для практикующих врачей. Для изучения признанный стандарт — Машков.
@saratovdae точно, не учёл этого. Тогда выкидывать устаревшие брони и при проверке бронирования, и при запросе остатка на складе. Иначе либо ставить частый крон, либо иметь задержку в обновлении брони. Надо просто провести проверку, какой вариант работает быстрее и есть меньше ресурсов.
Можно без крона - выкидывать истекшие брони на этапе проверки бронирования. Это чуть увеличит время на проверку (если грамотно сделать - то совсем незаметно), зато позволит избавиться от лишних запущенных процессов и снизит количество зависимостей скрипта (от планировщика).
