Существует ли оптимальный размер байта для отправки данных по сети?

Если Вы можете, просто позволить стеку IP обработать его; большинство Ose имеет большую оптимизацию, уже встроил. Vista, например, динамично изменит различные параметры для максимизации пропускной способности; пересмотр алгоритма вряд ли будет выгоден.

Это особенно верно на языках высшего порядка, далеко от фактического провода, как C#; существует достаточно слоев между Вами и фактическими пакетами TCP/IP, что я ожидал бы, что Ваш код окажет относительно мало влияния на пропускную способность.

В худшем случае протестируйте различные размеры сообщения в различных ситуациях для себя; немного решений едины.

Нет, нет никакого универсального оптимального размера байта.

Пакеты TCP подвергаются фрагментации, и в то время как было бы хорошо предположить, что все отсюда до Вашего места назначения - истинный Ethernet с огромными размерами пакета, действительность - то, даже если можно получить размеры пакета всех отдельных сетей, которые берет один из пакетов, каждый пакет, который Вы отсылаете, может выбрать другое путь через Интернет.

Это не проблема, которую можно "решить" и нет никакого универсального идеального размера.

Подайте данные к стеку OS и TCP/IP так быстро, как Вы можете, и это динамично адаптирует размер пакета к сетевым соединениям (необходимо видеть код, который они используют для этой оптимизации - это действительно, действительно интересно. По крайней мере, на лучших стеках.)

При управлении всеми сетями и используемыми стеками и промежуток клиенты/серверы, тем не менее, затем, можно сделать некоторую ручную настройку. Но обычно даже затем у Вас должно было бы быть действительно хорошее схватывание сети и данных Ваша отправка, прежде чем я предложу, чтобы Вы приблизились к нему.

- Adam

При использовании TCP/IP по Ethernet максимальный размер пакета составляет приблизительно 1 500 байтов. При попытке отправить больше, чем тот сразу, то данные будут разделены на несколько пакетов прежде чем быть отосланным на проводе. Если данные в Вашем приложении уже packetized, то Вы могли бы хотеть выбрать размер пакета только под 1500 так, чтобы при отправке полного пакета базовый стек не разбивал его. Например, если каждый отправлять Вы делаете 1 600 байтов, стек TCP должен будет отослать два пакета для каждого, отправляют, при этом второй пакет главным образом пуст. Это довольно неэффективно.

Однако я не знаю большую часть видимого влияния на производительность, которую это будет иметь.

Одна вещь, которую я добавлю, состоит в том, что для данного соединения Ethernet это сопровождает настолько же долго для отправки небольшого пакета как большой. Как других сказали: если Вы просто отправляете, поток данных позволил системе обработать его. Но если Вы волнуетесь по поводу отдельных коротких сообщений назад и вперед, типичный пакет Ethernet составляет приблизительно 1 500 байтов - пока Вы сохраняете его, под которым необходимо быть хорошими.

Я полагаю, что Ваша проблема состоит в том, что Вы используете блокирующиеся сокеты и не неблокирующиеся.

Когда Вы используете блокирующиеся сокеты, и Вы отправляете 1M данных, сетевой стек может ожидать всех данных, которые будут помещены в буфер, если буферы будут полны, то Вы будете заблокированы, и Ваш индикатор выполнения будет ожидать целого 1M, чтобы быть принятым в буферы, это может требовать времени, и Ваш индикатор выполнения будет нервным.

Однако при использовании неблокирующихся сокетов независимо от того, что размер буфера, который Вы используете, не заблокируется, и необходимо будет сделать ожидание сами с select/poll/epoll/whatever-works-on-your-platform (выбор является самым портативным хотя). Таким образом Ваш индикатор выполнения будет обновлен быстро и отразит наиболее достоверную информацию.

Действительно обратите внимание, что в отправителе индикатор выполнения частично повреждается любой путь, так как ядро буферизует некоторые данные, и Вы достигнете 100%, прежде чем другая сторона действительно получила данные. Единственный путь вокруг этого состоит в том, если Ваш протокол включает ответ на объем данных, полученный получателем.

Как другие сказали, второе предположение ОС и сети главным образом бесполезно, если Вы продолжаете использовать блокирующийся выбор сокетов размер, который является достаточно большим для включения большего количества данных, чем единственный пакет так, чтобы Вы не отправляли слишком небольшие данные в пакете, поскольку это уменьшит Вашу пропускную способность напрасно. Я пошел бы с чем-то как 4K для включения по крайней мере двух пакетов за один раз.

Необходимо было бы использовать Путь Исследование MTU или использовать хорошее значение по умолчанию (т.е. меньше чем 1 500 байтов).

Заставьте функцию под названием CalcChunkSize Добавить некоторые частные переменные к Вашему классу:

Private PreferredTransferDuration As Integer = 1800 ' milliseconds, the timespan the class will attempt to achieve for each chunk, to give responsive feedback on the progress bar.
Private ChunkSizeSampleInterval As Integer = 15    ' interval to update the chunk size, used in conjunction with AutoSetChunkSize. 
Private ChunkSize As Integer = 16 * 1024           ' 16k by default  
Private StartTime As DateTime
Private MaxRequestLength As Long = 4096            ' default, this is updated so that the transfer class knows how much the server will accept      

Перед каждой загрузкой блока проверьте если его время для вычисления нового chunksize использование ChunkSizeSampleInterval

            Dim currentIntervalMod As Integer = numIterations Mod Me.ChunkSizeSampleInterval
            If currentIntervalMod = 0 Then
                Me.StartTime = DateTime.Now
            ElseIf currentIntervalMod = 1 Then
                Me.CalcChunkSize()
            End If

numIterations установлен на 0 внешней стороны цикл загрузки и после того, как каждый загруженный блок установит на numIterations + = 1

Имейте CalcChunkSize, делающий это:

Protected Sub CalcAndSetChunkSize()
    ' chunk size calculation is defined as follows 
    ' * in the examples below, the preferred transfer time is 1500ms, taking one sample. 
    ' * 
    ' * Example 1 Example 2 
    ' * Initial size = 16384 bytes (16k) 16384 
    ' * Transfer time for 1 chunk = 800ms 2000 ms 
    ' * Average throughput / ms = 16384b / 800ms = 20.48 b/ms 16384 / 2000 = 8.192 b/ms 
    ' * How many bytes in 1500ms? = 20.48 * 1500 = 30720 bytes 8.192 * 1500 = 12228 bytes 
    ' * New chunksize = 30720 bytes (speed up) 12228 bytes (slow down from original chunk size) 
    ' 

    Dim transferTime As Double = DateTime.Now.Subtract(Me.StartTime).TotalMilliseconds
    Dim averageBytesPerMilliSec As Double = Me.ChunkSize / transferTime
    Dim preferredChunkSize As Double = averageBytesPerMilliSec * Me.PreferredTransferDuration
    Me.ChunkSize = CInt(Math.Min(Me.MaxRequestLength, Math.Max(4 * 1024, preferredChunkSize)))
    ' set the chunk size so that it takes 1500ms per chunk (estimate), not less than 4Kb and not greater than 4mb // (note 4096Kb sometimes causes problems, probably due to the IIS max request size limit, choosing a slightly smaller max size of 4 million bytes seems to work nicely) 
End Sub

Затем просто используйте ChunkSize, когда запрос затем разделяет на блоки.

Я нашел это в "Передающих файлах в блоках с веб-сервисами MTOM и.Net 2.0" Tim_mackey и нашел очень полезным сам динамично вычислить самый эффективный chunksize.

Исходный код полностью здесь: http://www.codeproject.com/KB/XML/MTOMWebServices.aspx

И автор здесь: http://www.codeproject.com/script/Membership/Profiles.aspx?mid=321767

Один эмпирический тест, который можно сделать, если Вы уже не имеете, должен, конечно, использовать сниффера (tcpdump, Wireshark и т.д.) и взгляд на то, для чего размеры пакета достигаются при использовании другого программного обеспечения/загружающий. Это могло бы дать Вам подсказку.

Вот формула, в которой Вы нуждаетесь:

int optimalChunkSize = totalDataSize / progressBar1.Width;

Используя это, каждый блок, который Вы отправляете, увеличит индикатор выполнения на 1 пиксель. Меньший размер блока, чем это бессмыслен, с точки зрения отзывов пользователей.