Как правильно отправлять и получать байты / файлы с помощью сокетов? - PullRequest
1 голос
/ 18 февраля 2012

У меня есть клиентская и серверная программа.Клиент отправляет файл на сервер, сначала преобразовав файл в байты, а затем отправив его на сервер.Затем сервер восстановит файл, используя полученные байты.У меня проблема с программой сервера.Иногда получаемые байты являются неполными.

Теперь я уже искал в Интернете и обнаружил, что это распространенная проблема среди начинающих программистов, таких как я.Я пробовал разные решения, которые нашел, но ничего не получалось.(Я работал над этим уже около 2 дней)

Мне было интересно, как правильно отправлять и получать файлы / байты между двумя программами в локальной сети?(Одна является сервером, а другая является клиентом, хотя, конечно, может быть более 1 клиентской программы, которая будет подключаться к серверной программе)

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

Некоторая дополнительная информация: я фактически основал свой код из этой темы форума: DANIWEB .Прочитав ветку, программа работала отлично и даже умудрилась отправить 400 МБ + видеофайл.В моем случае я отправляю только небольшие изображения и файлы документов размером менее 10 МБ, и моя серверная программа чаще всего завершается ошибкой.

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

Ответы [ 2 ]

2 голосов
/ 18 февраля 2012

Вы говорите «неполный» - это обычно указывает на одну из двух вещей:

  • у отправителя может быть включен "nagle", и последние несколько байтов все еще могут удерживаться на своем конце (OS / NIC), пока не станет доступен достаточно большой пакет. Значение: несмотря на то, что они вызвали Send / Write / etc - он все еще не покинул клиентский компьютер. Это не неожиданно. Они могут заставить его отправлять, закрывая сокет (или, по крайней мере, отправляя-выключая) или отключая nagle (установите NoDelay = true) и беря на себя ответственность за не слишком частое фрагментирование (BufferedStream может быть полезным для этого)
  • приемник не всегда получает целые кадры; при любом чтении / BeginRead / ReceiveAsync / и т. д. все, что вам гарантировано, это «несколько байтов» или «EOF». Таким образом, вы должны продолжать читать, пока у вас не будет конкурирующего кадра. Тогда возникает вопрос: как определяется фрейм вашим протоколом? Обычные подходы включают префикс длины (или длину в заголовке) или специальную последовательность завершения кадра

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

1 голос
/ 18 февраля 2012

Сложно ответить, я настоятельно рекомендую вам Socket Framework на платформе .net. Это сэкономит вам много времени на самостоятельную разработку. SuperSocket

...