Синхронное подключение NSURLC и использование порта?

Из iPad я использую NSURLRequest для опроса файла на http-сервере в моей WLAN. Я читаю файл раз в секунду. Я использую следующий код для чтения файла.Синхронное подключение NSURLC и использование порта?

NSURLRequest *request = [NSURLRequest requestWithURL:myURL 
            cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData 
            timeoutInterval:30.0]; 

// Get the data 
NSURLResponse *response; 
NSError *dataError; 
NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&dataError ];

Запуск NETSTAT на сервере показывает следующую сетевую активность (где 10.0.1.11 является IP-адрес IPad, который опрашивает сервер:

Proto Local Address   Foreign Address  State 
    TCP 10.0.1.16:80   10.0.1.11:56999  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57010  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57011  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57012  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57013  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57014  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57015  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57016  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57017  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57018  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57019  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57020  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57021  TIME_WAIT 
    TCP 10.0.1.16:80   10.0.1.11:57022  ESTABLISHED

Стоит ли беспокоиться, что существует несколько порты, используемые на стороне iPad? Должен ли я как-то «закрыть» NSURLConnection после чтения? Я использую ARC.

источник

2014-02-07 Electro-Bunny

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

В конечном итоге это сработает, но вы накладываете много накладных расходов на сервер и клиент таким образом. Если многие клиенты делают это, you can definitely overwhelm the server.

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

источник

2014-02-08 04:23:31

Я не разбираюсь в сетевых разговорах ... когда вы описываете длительный опрос как прослушивание новых сообщений с сервера, действительно ли вы хотите услышать ответ? Я предположил, что сообщения инициируются клиентом и ждут ответа с сервера? Будут делать еще немного чтения на длительном опросе. Во всяком случае, я получаю картину, что опрос 1 Гц плох по нескольким причинам, в частности потребляемая мощность на стороне iPad/Client из-за того, что Wi-Fi активен? –

Для того, что стоит, уменьшение частоты опроса, похоже, позволило лучше повторить использование исходящих портов iPad. Спасибо за указатели. –

Описанный здесь метод «длинного опроса» охватывает: https://en.wikipedia.org/wiki/Push_technology#Long_polling. Вы подключаетесь к серверу и запрашиваете «следующее обновление». Он не отвечает вам, пока на самом деле не появится обновление. –

Фактически NSURLConnection будет закрыт после завершения запроса. Вы отправляете эти запросы в другой читать?

Если да, я считаю, что то, что вы видите в netstat, - это открытые подключения к серверу. Кажется, что каждый запрос занимает больше времени, чем 1 секунда, так что вторая и третья и четвертая соединения устанавливаются (и так далее).

источник

2014-02-08 00:25:44 Shahin

Синхронное подключение NSURLC и использование порта?

ответ

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