TCP-сокет получает от неправильного порта - PullRequest
3 голосов
/ 14 марта 2012

У меня проблема с сокетом TCP, получающим сообщения с неверным портом назначения.

Операционная система - Ubuntu Linux 10.10, версия ядра 2.6.31-11-rt, но это также происходит и с другими ядрами.Программа C / C ++ с этой проблемой делает следующее:

  1. сокет TCP-сервера прослушивает соединения в INADDR_ANY через порт 9000.

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

  3. Ошибка: получатель сообщения TCP также получает сообщения на другие порты, отличные от 9000.Например, когда удаленный SFTP-клиент подключается к ПК, на котором прослушивает получатель TCP-сообщения, он заставляет получателя TCP-сообщения также получать SFTP-сообщения.Как это когда-либо возможно?Как порты TCP могут «протекать» таким образом?Я думаю, что SFTP должен использовать порт 22, верно?Тогда как это возможно, что эти сообщения видны в порту 9000?

Дополнительная информация:

  • В то же время есть необработанный сокет, который прослушивает другойсетевой интерфейс, и интерфейс находится в беспорядочном режиме.Может ли это иметь эффект?

  • Соединение TCP не закрывается между приемами сообщений.Слушатель сообщений просто продолжает читать данные из сокета.Это действительно правильный способ реализации получателя сообщения TCP?

Кто-нибудь видел подобную проблему?Заранее спасибо.

РЕДАКТИРОВАТЬ:

Хорошо, вот код.Код выглядит нормально, поэтому самое странное то, как сокет TCP может принимать данные, отправленные на другой порт?

/// Create TCP socket and make it listen to defined port
TcpSocket::listen() {
    m_listenFd = socket(AF_INET, SOCK_STREAM, 0)
    ...
    bzero(&m_servaddr, sizeof(sockaddr_in));
    m_servaddr.sin_family = AF_INET;
    m_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    m_servaddr.sin_port = htons(9000);
    bind(m_listenFd, (struct sockaddr *)&m_servaddr, sizeof(sockaddr_in);
    ...
    listen(m_listenFd, 1024);
    ...
    m_connectFd = accept(m_listenFd, NULL, NULL);
}

/// Receive message from TCP socket.
TcpSocket::receiveMessage() {
    Uint16 receivedBytes = 0;
    // get the common fixed-size message header (this is an own message structure)
    Uint16 numBytes = recv(m_connectFd, msgPtr + receivedBytes, sizeof(SCommonTcpMSGHeader), MSG_WAITALL);
    ...
    receivedBytes = numBytes;
    expectedMsgLength = commonMsgHeader->m_msgLength;   // commonMsgHeader is mapped to received header bytes
    ...
    // ok to get message body
    numBytes = recv(m_connectFd, msgPtr + receivedBytes, expectedMsgLength - receivedBytes, MSG_WAITALL);
}

Ответы [ 2 ]

0 голосов
/ 15 марта 2012

Умм ... Похоже, это был необработанный сокет после всех, кто получил сообщения.Из журнала видно, что это необработанный обработчик сообщений, распечатывающий прием сообщений, а не обработчик сообщений TCP.Duh ...!: S Извините.Поэтому кажется, что привязка необработанного сокета к другому сетевому интерфейсу работает неправильно.Нужно это исправить.Забавно, что иногда он работает с SSH / SFTP, иногда нет.

0 голосов
/ 15 марта 2012

Соединение TCP не закрывается между приемами сообщений.Слушатель сообщений просто продолжает читать данные из сокета.Действительно ли это правильный способ реализации получателя сообщения TCP?

Да, но он должен закрыть сокет и завершить работу при получении индикации EOS (recv () возвращает ноль).

Я думаю, что десять к одному ваши сырые сокеты и FD сокетов TCP где-то перепутаны.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...