Вы уж опишите конкретнее, что именно за услугу вы имеете ввиду, а то под виртуальными номерами наши операторы понимают разные вещи. Не название, а функционал, что именно они предлагают.
Нет инпута? А вы рендерите шаблон с помощью render_to_response? Тогда передавайте ему RequestContext. А проще — сразу рендерить с помощью django.shortcuts.render, куда первым параметром идёт request, потом шаблон и третий необязательный — dict с данными шаблона.
Да, действителньно, я должен был написать так: select(...) не вернётся, а если вернётся, то этот сокет не будет в списке read_set, а если будет, то с ним будет связано событие, что соединение закрыто. Справедливости ради, как выяснилось, в node.js хорошо абстрагировано сетевое api и нет вообще никакого select, нас могут не понять :)
Так или иначе, данных в сокете не будет ни в каком другом случае, кроме «пришёл пакет с нужным seq».
По поводу seqno в syn-пакете: вы заблуждаетесь, он СЛУЧАЙНЫЙ. Он именно произвольный, какое-то число, которое произвольным образом выбрала передающая сторона. SYN-пакет и определяет в начале соединения: «вот этот номер считать началом отсчёта». Wireshark по умолчанию показывает относительные SEQ, вычисляется номер байта относительно SEQ в SYN-пакете, то есть SEQ-SEQ[SYN], и таким образом для SYN-пакета Wireshark покажет 0. Но там явно написано — «relative». Если вы посмотрите на дамп пакета, увидите там некое (в идеале) непредсказуемое число.
(Кстати, если система генерирует предсказуемые SEQ в SYN-пакетах, она окажется уязвимой для некоторых атак на стек TCP.)
Разделяйте транспортный уровень и сетевой. На уровень tcp (транспортный) передаются уже собранные пакеты, если они были фрагментированы — слой tcp опять не получит пакет, пока все его фрагменты не собраны (на сетевом уровне). То же самое касается других протоколов этого уровня: udp-пакет можно фрагментировать и он или «дойдёт целиком и в правильном порядке» или «не дойдёт совсем».
А в вашем случае вроде пакеты целые, не фрагментированные.
Нет у пакета никакого идентификатора. PSH — это не номер пакета, это флаг (0 или 1, других не будет). То, что вы в Wireshark увидели данные в произвольном порядке — следствие того, что вы получили их через pcap в обход tcp-стека, т.е. в обход всей логики ОС по упорядочению и гарантиям доставки.
В вашем случае, поведение системы предсказать нельзя, т.е. вы предоставили недостаточно данных. Нужно было бы знать seqno пакета с флагом «syn»: 1, а вы такой пакет то ли не захватили, то ли забыли здесь указать.
Если предположить, что первый пакет в данном соединении реально «первый», то у syn-пакета в вашем случае seqno был равен 1455343061, и ваше приложение, слушающее сокет, не получит вообще никаких данных и событий от этого сокета (например, select(...) не вернётся, а если вернётся, то этот сокет не будет в нём readable), пока система не получит пакет с seq=1455343061, после получения которого она данные из него отдаст приложению, а сама добавит к этому числу размер пакета (в данном случае — 1440), и следующим приложению будут выданы данные из пакета с seqno = 1455343061+1440 = 1455344501, каким бы он по порядку ни пришёл из сети.
lex_t, нумеруются не пакеты, нумеруются байты. Теоретически в процессе передачи можно разделить пакет на части или наоборот склеить пакеты или перераспределить байты по ним, но порядок сохранить — прикладной уровень ничего не заметит. Поле SEQ — это порядковый номер первого байта в пакете.
не, разница есть. iptables — это обычный iptables. а ebtables ничего не знает про ip-адреса и так далее. Т.е., например, с iptables и echo 1 > /proc/net/bridge/brighe-nf-call-iptables я получу возможность сопоставлять mac и ip отправителя, фразы вроде iptables --physdev-in tap0 --physdev-out eth0 -s 1.2.3.4 -m mac! --mac-source 00:11:22:33:44:55 -j DROP — с ebtables вы этого не сделаете
Но — точно не ядра. На parted magic с ядрами 3.x (того же порядка, что и в генте) — производительность как в дебиане. Я думаю, что тут всё дело в libc.
Я вот заметил: вижу явного чудика или придурка с очередным бредом, иду к нему в карму — а там уже за несколько десятков минусов. Вот и сейчас…
Я на самом деле ваш ник запомнил, полез, чтобы только убедиться. Ибо неоднократно наблюдал с вашей стороны неразумные или неадекваные суждения здесь. Ну или просто неприятие очевидных и доказаных фактов.
Как пример, непонятно, что вы вообще на этом «сайтишке» забыли, раз оно такое «сайтишко».
WarP, вы хотите либо энтерпрайс функции от дешёвого оборудования (чего никто не станет делать), либо хотите функции, которые никому не могут понадобиться (люди с нормальными квмами обычно не покупают дешёвое оборудование). В общем, почему-то я уверен, что в массовом производстве вы такую странную штуку не найдёте.
как вариант — ddos mail.ru посредством браузеров клиентов заращённых сайтов
насчёт «мейлру просто не работает» — ну так на главной может быть логика, чтоб определить, как именно клиент попал на сайт — по вот такой хрени из джаваскрипта или же адрес в строке вбил
