«IP в сети выставляются руками»
не влияет на возможность использования NAT, единственное что, не уверен, что маппинг адрес-в-адрес возможен если у вас снаружи оба адреса из разных сетей с разными шлюзами.
Совершенно точно под стек. Начиная с какой-то из версий 2.6 дефолтный размер стека стал 10 мегабайт. Выход — указывать явно, что-нибудь типа:
pthread_attr_init(&pa);
pthread_attr_setstacksize(&pa,PTHREAD_STACK_MIN + 16384);
result = pthread_create(&thread1, &pa, new_connection,s)
(только если это будет переноситься на другие платформы — имейте ввиду, что там в 64-битных версиях FreeBSD PTHREAD_STACK_MIN неправильно определен, надо давать с запасом)
С фамилией Бляхерман тоже были проблемы.
Писал подобную функцию на C, с нормализацией, чтобы нельзя было буковки на циферки менять и т.п., если надо — поделюсь.
Да, последний вариант. Необходимо включить в SPF политику запись гугла, иначе вы ему политикой не разрешаете письма доставлять с адресов вашего домена.
Более того, в сетях с очень большой потерей пакетов TCP в принципе не выживет, а построить протокол поверх UDP который будет работать даже при 90% потере пакетов можно.
По первому пункту — не понятно что значит «найти», по каким критериям найти, где и в какой момент? Если надо какие-то файлы просто копировать юзеру при логоне в профиль — сделайтe на сетевом диске папку со структурой подпапок и юзеру при входе делайте что-то типа
xcopy /U /T /H /Y \\path\to\network\*.* %UserProfile%
при этом будут заменяться только файлы которые уже имеются.
Если вошел на тот же компьютер — то не потерял, если на другой — то потерял. Опять же возможны нехорошие ситуации, когда юзер входит на один компьютер, забывает выйти, входит на другой, что-то делает, сохраняет в локальный профиль, логофится, синхронизуется, после чего его логофят на первом компьютере, тот тоже синхронизует профиль и изменения сделанные юзером теряются.
В общем, приучайте студентов стараться работать на одном и том же компьютере, если есть проблемы в сети, тогда все будет хорошо. А иначе, кстати, их и кэширование учетной записи не спасет.
Вариант с линуксом не покатит, т.к. пока нет поддержки для встроенного в A10 аппаратного видео-декодера (не путать с 3D-акселератором). На форуме xbmc активно обсуждается проблема, была надежда что Allwinner выдаст библиотеку для декодирования в открытый доступ, но что-то она угасает.
Правильные терминаторы \r\n, но при этом может сам скрипт заменять \n на \r\n, может MTA это делать, это надо учитывать, в результате может быть наоборот лишний \r + убедитесь что в конце текста перевод строки есть. h= в RFC 4870 не обязателен, в RFC 4871 он обязателен, т.к. иначе в бою все будет фейлиться из-за заголовков которые MTA добавляют, например при пересылке.
Ну как минимум у вас нет заголовка h=, поэтому если какие-то заголовки (например Date или Message-ID) добавляется после подписи, сервер некорректно валидирует письмо. Так же nofws выбран только для заголовков, возможно в тексте у вас некорректные терминаторы строк, которые меняются при передаче после подписи.
P.S. резюмируя —
ping -l 1500
можно использовать когда точно не известен MTU на данном компьютере и надо определить нет ли проблемы с blackhole.
ping -l 1472 -f
имеет смысл использовать, когда известно, что MTU на локальной системе равен 1500
ping -l 1500 -f
не будет работать никогда.
Если размер IP пакета больше больше чем MTU то он фрагментируется при отправке, а любой фрагмент уже имеет установленный бит DF. Поскольку 1500 больше чем 1472 (максимальный размер данных ICMP убирающихся в IP-пакет 1500 байт), то этот пинг будет фрагментированными пакетами и как раз таки -f здесь ни на что не влияет.
Единственное, можно было бы упустить ситуацию когда MTU установлен существенно больше дефолтных 1500.
Скорее всего по какой-то другой причине пинги проходили а TCP нет, например на пинги отвечает одна железка с маленьким MTU, а TCP соединения у гугла заворачиваются на другую железку, с бОльшим MTU/MSS.
