2012-02-01 2 views
2

Я разрабатываю приложение для синхронизации файлов (например, DropBox). Клиент поддерживает постоянный TCP-сокет Secure (SSL) с сервером на порту 443. Всякий раз, когда файл создается, изменяется/удаляется на клиенте, пакет, содержащий соответствующие данные, отправляется через сокет на сервер, который обрабатывает его до обновите файл на сервере. Аналогично, когда что-то меняется на сервере, он отправляет соответствующие данные клиенту, который затем обновляет локальную копию.Рекомендации по программированию сокетов?

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

Например, скажем, когда файл создается на Клиенте, должен ли клиент просто отправлять данные на сервер и забывать об этом, или он должен ждать подтверждения с сервера в течение определенного периода времени, которые отправляют данные снова? И какое признание?

ответ

5

TCP абстрагирует многие сетевые проблемы: пакеты всегда поступают в порядке и повторно отправляются, если сервер не признает, что получил пакет. Недопустимая сеть приведет к замедлению трафика, поскольку пакеты должны быть повторно отправлены.

Если соединение все равно утеряно, ваши вызовы read() и write() возвращают значения возврата, поэтому вам придется это обработать.

+0

О, это хорошо.Поэтому мне не нужно беспокоиться о потерянных пакетах. Но я думаю, мне все равно придется отправлять подтверждения в прикладном уровне как «nos», упомянутые в комментарии к приведенному ниже ответу. –

+0

Так что мое приложение просто продолжает толкать данные в сокет, не беспокоясь ни о чем. Например, скажем, клиент должен отправить файл на 10 ГБ на сервер, а соединения очень медленные. Должно ли приложение просто записывать данные в выходной буфер? Если сеть медленная, не переполнение буфера? –

+0

Если вы используете что-то вроде [sendfile (2)] (http://linux.die.net/man/2/sendfile), он вернет количество байтов, которое ему удалось записать. Затем вы можете опросить FD для готовности к записи и попробовать написать еще несколько. –

0

Клиент сохраняет постоянный Secure (SSL) TCP сокет с сервером

[..]

если клиент просто отправить данные на сервер и забыть об этом, или же она должна дождитесь подтверждения с сервера в течение определенного периода времени, если не удается отправить данные снова?

Если вы используете UDP, вам нужно будет это сделать. Но поскольку вы используете TCP, все это уже сделано для вас.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

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

+2

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

+0

Это выходит за рамки «программирования сокетов», нет? –

+0

Спасибо за комментарии ребята, какой-нибудь ответ на мой комментарий на ответ Сьёрда выше? –

0

Вы должны использовать подтверждение, даже если сервер является localhost. Представьте, что при отправке информации возникает проблема с подключением. Вам нужно каким-то образом узнать результат операции (например, с помощью системы подтверждения).

Я бы использовал что-то более сложное, чем простой ответ ACK/NACK. Например, если вы изменили некоторые файлы на клиенте, после отправки информации от клиента на сервер, сервер должен ответить на номер (или список с именем) файлов, затронутых операцией обновления. Таким образом, клиент может проверить, что все прошло нормально, или действовать в результате.

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