Пожалуйста, предложите другие способы связи между сервером и клиентом

Question

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

• чат между пользователями (дох), он будет многопоточным
• отправка друг другу файлов

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

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

• каждый раз, когда клиент / сервер хочет что-то отправить (текстовое сообщение или файл), он сначала отправляет простое текстовое сообщение (новая строка прекращается) с количеством чанков, которые он отправит. Пример:

  команда 4,20,30,40,50

Где command будет что-то вроде instant-message или file, 4 будет количеством отправляемых чанков, 20 будет размером в байтах первого чанка, 30 вторым и т. Д. .

• после того, как сообщение было отправлено, клиент / сервер начнет отправлять куски (размеров, указанных в отправленном сообщении).

Что вы думаете о такой реализации взаимодействия клиент / сервер? Какие есть лучшие варианты?

Answer 1

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

Кроме того, чтобы клиентское программное обеспечение не выполняло функции как сервера, так и клиента (имеется в виду необходимость решения проблем идентификации одноранговых узлов), вы могли бы общаться со всеми клиентамичерез централизованный сервер.

Answer 2

Глупый вопрос: почему бы не использовать протокол TELNET через TCP / IP для потока чата и что-то вроде FTP через TCP / IP для передачи файлов?

Answer 3

Довольно типичным решением здесь являются веб-сервисы, использующие SOAP.

Answer 4

Я мог бы передавать XML между клиентами; это бы сработало.

Для передачи файлов, возможно, просто пропустите байтовый буфер; Я думаю, единственная проблема, если вы работаете между машинами с высоким и низким порядком байтов.

Answer 5

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

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