2013-08-18 2 views
0

Хорошо из моих знаний UDP работает как это:UDP отправка данных, что-то Я не совсем понимаю,

У вас есть данные, которые вы хотите отправить, вы говорите клиенту UDP, эй отправить эти данные.

Клиент UDP затем говорит, конечно, почему нет, и отправляет данные на выбранный IP-адрес и порт.

Если это происходит или находится в правильном порядке, это еще одна история, она отправила данные, вы ничего не просили.

Теперь с этой точки зрения невозможно отправить данные и собрать их. например, у меня есть изображение 1 МБ, и я его отправляю.

Поэтому я отправляю его в файлы размером 60 КБ (или что-то, что подходит для пакетов), и отправляйте их по одному от первого до последнего.

В теории, если все добавлены, изображение должно быть точно таким же.

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

Во всяком случае, то, что я хочу, чтобы понять, почему это работает:

void Sending(object sender, NAudio.Wave.WaveInEventArgs e) 
    { 
     if (connect == true && MuteMic.Checked == false) 
     { 
      udpSend.Send(e.Buffer, e.BytesRecorded, otherPartyIP.Address.ToString(), 1500); 
     } 
    } 

ПОЛУЧАТЬ:

 while (connect == true) 
     { 
      byte[] byteData = udpReceive.Receive(ref remoteEP); 
      waveProvider.AddSamples(byteData, 0, byteData.Length); 
     } 

Так что это в основном, он посылает звуковой буфер через UDP.

Принимающий пар просто добавляет данные udp, полученные в буфере, и воспроизводит их.

Теперь это работает.

И мне интересно .. почему?

Как это работает, как данные отправляются в правильном порядке и добавляются, поэтому он отображается как постоянный поток аудио?

Причина, если бы я сделал это с изображением, я бы, вероятно, получил все данные.

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

Так что, если кто-то может объяснить это, я просто не понимаю.

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

Отправить:

      using (var udpcap = new UdpClient(0)) 
          { 
           udpcap.Client.SendBufferSize *= 16; 
           bsize = ms.Length; 
           var buff = new byte[7000]; 
           int c = 0; 
           int size = 7000; 
           for (int i = 0; i < ms.Length; i += size) 
           { 
            c = Math.Min(size, (int)ms.Length - i); 
            Array.Copy(ms.GetBuffer(), i, buff, 0, c); 
            udpcap.Send(buff, c, adress.Address.ToString(), 1700); 
           } 

Прием:

    using (var udpcap = new UdpClient(1700)) 
        { 
         udpcap.Client.SendBufferSize *= 16; 
         var databyte = new byte[1619200]; 

         int i = 0; 
         for (int q = 0; q < 11; ++q) 
         { 
          byte[] data = udpcap.Receive(ref adress); 
          Array.Copy(data, 0, databyte, i, data.Length); 
          i += data.Length; 
         } 
         var newImage = Image.FromStream(new MemoryStream(databyte)); 
         gmp.DrawImage(newImage,0,0); 
         } 

ответ

0

Вы упускаете много полезных детали из вашего вопроса, но, основываясь на уровне понимания представленного я попытаюсь ответить на аналогичный уровень:

Вы абсолютно правы, в общем, протокол UDP не гарантирует порядок доставки или даже доставку вообще. Ваш локальный хост отправит пакеты (т. Е. Части вашего сообщения запроса) в том порядке, в котором он их получает, от отправляющего приложения, а оттуда - до сетевых компонентов, чтобы решить, как будет доставлен ваш запрос. Однако в локальных сетях (в пределах горстки хэп оригинального реквестера) на самом деле не так много направлений для пакетов. По существу, они, скорее всего, просто вливаются в линию и никогда не видят икоту.

В случае большего интернета, однако, существует большой выбор маршрутов, доступных каждому маршрутизатору между вашим запрашивающим хостом и пунктом назначения. Каждый маршрутизатор по пути может сделать выбор в том направлении вашего сообщения. Предполагая, что все пути равны (что они не являются) и гарантируют надежность каждого сегмента сети между двумя хостами, он может увидеть аналогичные результаты, как в сети (с добавленной задержкой). К сожалению, ни один из поставленных условий не может считаться надежным (разные пути в Интернете работают по-разному в зависимости от клиента и сервера, и ни один путь в Интернете не должен считаться надежным (поэтому он является «сетью»).

...

это, конечно, на основе общих наблюдений из моего собственного опыта поддержки и администратора ролей сети Члены других сайтов StackExchange могут быть в состоянии обеспечить лучшую обратную связь

+0

Я понимаю, что если это в локальной сети, будет более постоянный поток, поскольку нет ничего, что вызовет «неприятность». Но пример Udp, который я дал, был в Интернете, он работает повсюду, поэтому я считаю его странным. – Zerowalker

+0

Факт остается фактом: если вы говорите о _anywhere_ в Интернете, вы должны ожидать некоторую потерю/рассогласование пакетов с UDP. Я был сожжен отсутствием гарантированной доставки UDP более одного раза после проверки исходных тестов. Если вы не хотите присоединиться к нам неудачно, вы все равно будете котироваться против него (или вообще избегайте его). –

+0

Ну, дело в том, что звук не полностью перепутан, он должен быть искажен, поскольку пакеты должны поступать в случайном порядке. Я знаю, что другие вещи полностью повреждены без привязки к безопасности. – Zerowalker

1

Вы должны использовать TCP Вы пишете: это практически невозможно отправить данные и собрать их, например, у меня есть изображение в 1 мб, и я отправляю его. Поэтому я отправляю его в файлы размером 60 КБ (или что-то, что подходит для пакетов), и отправляю их по одному от первого до последнего. ... Но эта теория ломается, поскольку нет закона, который сообщает пакетам, если он может прибыть быстрее или медленнее другого, поэтому это возможно только в том случае, если вы сделаете какой-то таймер ожидания и надеетесь на лучшее, что прибудет в том порядке, в котором они отправлены. Это именно то, что делает TCP: убедитесь, что все части потока данных получены в том порядке, в котором они были отправлены, без каких-либо упущений, дублирования или модификаций. Если вы действительно хотите повторно реализовать это самостоятельно, вы должны читать RFC 793 - он подробно рассказывает о том, как построить надежный поток данных поверх ненадежной службы пакетов.

Но на самом деле, просто используйте TCP.

Смежные вопросы