2010-08-25 3 views
1

Каковы возможные варианты передачи большого количества данных с одного компьютера на другой не в той же локальной сети. Объем данных составляет около 100 Мб для распаковки и 2 Мб заархивирован? Другое требование заключается в том, что когда я создаю сервер для этого (с C#), клиенты Java должны его использовать.Как передать большое количество данных между двумя компьютерами

  • Поддерживает ли WCF что-то вроде этого? Но если клиенты Java не смогут его использовать, мне это неинтересно.
  • Какие здесь могут быть другие стратегии?
+0

Интернет-трубы должны выполнять работу –

ответ

2

Я бы использовал что-то общее, например, HTTP или FTP, так как для этого будет много существующих библиотек, и вы почти наверняка не будете иметь проблем с совместимостью. 2MB не является необоснованно большим объемом данных для этих протоколов.

+0

Поддерживает ли HTTP-запрос gziped REQUESTS? –

+0

Несомненно, вы можете просто gzip данные, прежде чем включать его в тело запроса. (Но я не думаю, что вы можете использовать заголовок Content-Encoding в запросе.) –

0

В C# вы можете сериализовать свой объект как XML и передавать, а на другом конце вы можете десериализовать свой XML обратно к объекту.

С точки зрения размера файлов, вы можете передавать в виде zipped или 7z..and на клиенте распаковывать его перед разбором xml.

0

WCF поддерживает SOAP и включает в себя дополнительную сериализацию JSON для XHTTP. Существуют и другие механизмы, но они ориентированы на MS. Вы легко сможете использовать созданный вами сервис. Однако вам придется подумать о том, как закодировать данные, поскольку они попадут в провод в дружественном для двоичных данных (XML/JSON).

Возможно, вы захотите вместо этого создать простой обработчик HTTP, который может возвращать данные непосредственно в виде zip, используя соответствующие заголовки mime и т. Д. Затем вы можете просто нажать это, используя ваш Java-клиент.

0

XMPP - еще один вариант. Вам нужен другой сервер, но это может быть преимуществом: клиенту не нужно знать IP-адрес серверов, сервер и клиенты просто подключатся к серверу XMPP для обмена сообщениями и файлами.

Ссылки по теме (для Java):

0

Вы не упомянули, какой тип данных вы хотите отправить. Поэтому для упрощения вещей я предполагаю, что у вас есть поток данных, который можно преобразовать в массив байтов. Содержимое потока должно быть в формате, понятном как для C#, так и для Java!

Лучший вариант - сжатие потока данных потоком GZip. Gzip должен поддерживаться на Java. Затем вы можете отправить этот поток, преобразованный в массив байтов, в качестве ответа от вашей службы WCF. Вы можете использовать стандартную текстовую кодировку, которая преобразует байтовый массив в кодировку Base64. Если ваш java-клиент поддерживает MTOM (стандарт, поддерживаемый Java), вы можете использовать кодировку MTOM, которая использует более мелкие сообщения.

Если у вас нет потока с хорошо известным форматом контента, у вас есть какие-то пользовательские данные. Для пользовательских данных вы должны использовать совместимый транспортный формат, который представляет собой XML. Использование XML будет увеличивать размер ваших данных. В этом случае вам следует рассмотреть возможность деления вашей передачи данных на несколько вызовов. Вы также можете попробовать разместить свою службу WCF в IIS 7.x и воспользоваться ее встроенной функцией - сжатием динамического содержимого.Если ваш Java-клиент вызывает службу с заголовком HTTP-Accept-Encoding для сжатия, gzip автоматически сжимает ответ. Имейте в виду, что только клиенты .NET 4.0 WCF могут работать с такой услугой.

1

Это интересный вопрос. Вопрос довольно прост ответить. Но интересно то, что такие вопросы новы, они раньше не существовали. Позвольте мне объяснить, но сначала я отвечу на ваш вопрос:

Вы должны создать сервер и клиентов, используя старые TCP-потоки. Чтобы не появляться в полосе пропускания, вам нужно как-то сжать поток, здесь используйте один из самых распространенных алгоритмов сжатия, который вы можете найти (кто-нибудь сказал Zip?). Теперь у вас есть независимый от языка протокол. Клиенты на любом языке будут работать, миссия выполнена. Также, чтобы сохранить кросс-платформу, не выбирайте лучшее сжатие там, выберите наиболее распространенный (это будет достаточно хорошо).

Теперь, почему такие вопросы интересны, они показывают что-то о ООП в больших масштабах. Люди понимают и используют огромные рамки и спрашивают, может ли та или иная инфраструктура выполнять для них ту или иную простую задачу. Здесь мы потеряли свои корни, мы потеряли внутреннюю работу вещей, она ударяет ноготь не молотком, а ядерной ракетой. Это превышение цели, и оно будет создавать огромные приложения с огромным размером и часто плохими характеристиками.

Я считаю, что эти вопросы увеличились с тех пор, как ООП был полностью принят. Это похоже на то, что новые программисты хотят только изучить эти новые большие рамки и что структура сглаживает взгляд на мир. В больших рамках нет абсолютно ничего плохого, они замечательные, но я считаю, что неправильно начинать использовать их, прежде чем освоить основы. Это как научиться летать с помощью космического челнока НАСА вместо школьной версии частного самолета Cessna.

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