Лучше отправить 1 большой кусок или много маленьких при использовании TCP?
Вполне возможно, что люди, которые подписываются на вашу службу, вводят электронные письма с ошибками ввода, которые вы не исправляете. Например: chris@gmial.com -or- james@hotnail.com.
И такие домены сконфигурированы для использования в качестве spamtraps , которые автоматически помещают IP-адрес вашего почтового сервера и / или домен и повредить его репутации.
Чтобы избежать этого, выполните двойную проверку для адреса электронной почты, который вводится при подписке на продукт. Также отправьте электронное письмо с подтверждением, чтобы убедиться, что этот адрес электронной почты проверен на 100% человеком, который вводит письмо с подтверждением, прежде чем отправлять им ключ продукта или принять их подписку. Письмо с подтверждением должно требовать, чтобы получатель щелкнул ссылку или ответ, чтобы действительно подтвердить, что владельцем почтового ящика является человек, который зарегистрировался.
7 ответов
Клиент и сервер разобьет Ваши данные, как они считают целесообразным, таким образом, можно отправить так, как Вам нравится в одном блоке. Проверьте статья User's Guide to TCP Windows А Von Welch.
Алгоритм Nagle , который обычно включается по умолчанию на сокетах TCP, вероятно, объединится те четыре 256 побайтовых записей в тот же пакет. Таким образом, действительно не имеет значения при отправке его как одной записи или нескольких это должно закончиться в одном пакете так или иначе. При отправке его, поскольку один блок имеет больше смысла, если у Вас есть большой блок для начала.
-
1Запустите программу отдельно, откройте старую кодовую базу в VS и присоедините отладчик вручную. – Femaref 18 November 2011 в 21:52
При вычислениях данных между теми записями может быть лучше передать их потоком, поскольку они доступны. Кроме того, запись их внезапно может произвести переполнение буфера (хотя это, вероятно, редко, это действительно происходит), означая, что Ваше приложение должно приостановить и повторить записи (не все они, только от точки, где Вы поражаете переполнение.)
я обычно не старался бы изо всех сил разделять записи на блоки, особенно не всего 256-байтовые блоки. (Так как примерно 1 500 байтов могут поместиться в пакет Ethernet после TCP/IP наверху, я использовал бы блоки, по крайней мере, настолько большие.)
-
1Сделайте VM только с VS и кодовой базой. Контроль соответствующие нормы к новой папке и отладке это. Если Вы don' t хотят испортить Вашу текущую сборку, you' ll должны сделать что-то с немного большим количеством работы, Вы won' t обходят его. – Femaref 19 November 2011 в 00:58
Годы и несколько лет назад, у меня было приложение, которые отправляют двоичные данные - оно сделало каждый отправляет с размером следующего буфера, и затем другой отправляет с буфером (несколько сотен байтов). И после профилирования, мы обнаружили, что могли получить главное ускорение путем превращения их в один буфер и отправки его только однажды. Мы были удивлены - даже при том, что существует некоторая сеть наверху на каждом пакете, мы не думали, что это было значимым фактором.
-
1Я don' t хотят открыть различную кучу проблем, но я зарегистрировался и в скомпилированном исполняемом файле и в .pdb файлах (в теге, таким образом, it' s не в любом ответвлении). Так, у меня действительно есть все, в чем я нуждаюсь - я хочу к Visual Studio не сдуть его. – seeker 18 November 2011 в 21:44
От уровня TCP да будет разделен Ваш большой буфер, когда это будет слишком большим, и он будет объединен, когда это слишком маленькое.
От прикладного уровня, не позволяйте своему приложению иметь дело с неограниченные буферные размеры . На некотором уровне необходимо разделить их.
, Если Вы отправляете файл по сокету и возможно обрабатываете некоторые из данных этого файла, как сжатие его. Тогда необходимо разделить это на блоки. Иначе Вы будете использовать слишком много RAM, когда Вы в конечном счете случайно встретите большой файл, и Ваша программа будет вне RAM.
RAM не является единственной проблемой. Если Ваш буфер становится слишком большим, можно провести слишком много времени, читая в данных, или обрабатывая его, и Вы не будете использовать сокет, который находится, там ожидая данных. Поэтому лучше иметь параметр для размера буфера так, чтобы можно было определить значение, которое не является слишком маленьким, ни слишком большим.
Мое требование не состоит в том, что сокет TCP не может обработать большой блок данных, он может и я предложить использовать более крупные буферы при отправке для получения лучшей эффективности. Мое требование состоит в том, чтобы просто сделать не, имеют дело с неограниченными буферными размерами в Вашем приложении.
-
1Я хочу отладить инициализацию, таким образом, мне нужны точки останова на месте довольно вначале. – seeker 18 November 2011 в 22:54
Единственный абсолютный ответ должен представить приложение в случае, если. Существует столько факторов, что не возможно дать точный ответ thah, корректно во всех случаях.
-
1
Я отправил бы все в одном большом блоке как нижележащие слои в osi модель . Для этого Вы не должны волноваться о том, как большие блоки, которые Вы отправляете как слои, разделят их как necisarry.
-
1