2010-11-11 9 views
0

Je rencontre des problèmes avec une application cliente socket écrite en vb.net à l'aide de Visual Studio 2005. Le client se connecte à un serveur de socket en langage C qui s'exécute sur OpenVMS. Le problème que j'ai est que lorsque le serveur envoie un paquet, le client ne reçoit pas le dernier octet (de chaque paquet!). Je peux vider les paquets sur le réseau et les données sont toutes là. Ma solution actuelle est de garder mes messages de socket courts (247 octets) et d'envoyer un octet supplémentaire après la fin de mes données.Socket.Receive supprime le dernier octet de chaque paquet

Je voudrais inclure plus d'informations dans mes messages et je n'arrive pas à trouver un moyen de le faire fonctionner. Si je savais à 100% combien de temps les paquets seront sur le réseau, je pourrais contourner ce problème en ajoutant un octet supplémentaire aux bons endroits. Cependant, je ne veux pas faire d'hypothèses sur la longueur des paquets.

Quelqu'un at-il des suggestions sur la meilleure solution à ce problème?

Voici un échantillon de mon client code de réception:

Private Sub ReceiveMsg() 
    Dim nTotalBytes As Integer 
    Dim nNumBytes As Integer 
    Dim nMsgType As Short 
    Dim nMsgLen As Short 
    Dim ind As Integer 

    Try 
     nNumBytes = -1 
     While (nNumBytes <> 0) 

      nTotalBytes = 0 
      RecvBuffer.Initialize() 

      nNumBytes = ClientSocket.Receive(RecvBuffer, nTotalBytes, 4, SocketFlags.None) 
      If nNumBytes > 3 Then 
       SyncLock ClientSocket 
        AppendText("") 
        AppendText("Message Received " & Str(nNumBytes) & " Bytes") 
        nTotalBytes = nTotalBytes + nNumBytes 
        nMsgType = BitConverter.ToInt16(RecvBuffer, 0) 
        nMsgLen = BitConverter.ToInt16(RecvBuffer, 2) 
        If nMsgLen > 8191 Then 
         AppendText(" Error - Message length invalid: " & Str(nMsgLen)) 
         nMsgLen = 250 
        End If 

        While (nTotalBytes < nMsgLen And nNumBytes > 0) 
         nNumBytes = ClientSocket.Receive(RecvBuffer, nTotalBytes, (nMsgLen - nTotalBytes), _ 
                 SocketFlags.None) 
         AppendText("Message Received " & Str(nNumBytes) & " Bytes") 
         nTotalBytes = nTotalBytes + nNumBytes 
        End While 
       End SyncLock 

       AppendText("Total Bytes Received = " & Str(nTotalBytes)) 
       AppendText("MsgLen from Message = " & Str(nMsgLen)) 
       Select Case nMsgType 
        Case 1 
         AppendText(" Liftpos = " & System.Text.Encoding.ASCII.GetString(RecvBuffer, 4, 1)) 

         For ind = 0 To NUM_LOCATIONS - 1 
          Number(ind) = System.Text.Encoding.ASCII.GetString(RecvBuffer, 5 + (ind * 12), 12) 
         Next 

         RefreshScreen() 

        Case Else 
         AppendText(" Unrecognized message type: " & Str(nMsgType)) 

       End Select 

      End If 
     End While 


    Catch ex As Exception 
     ' Tell the main thread to invoke DisconnectedUI 
     Dim cb As New SimpleCallback(AddressOf DisconnectedUI) 
     Me.Invoke(cb) 
     Return 
    End Try 
+0

Je ne vois rien de mal. Ce qui est assez mystérieux, c'est comment * vous * pouvez résoudre ce problème en envoyant un octet supplémentaire. Vous avez dit que le message * server * manque un octet. –

Répondre

0

En fait, l'envoi d'un octet supplémentaire ne résout pas le problème. Tant que je garde mon message de socket sous environ 247 octets, tout est envoyé en un seul paquet. Par conséquent envoyer un octet supplémentaire s'assure juste que toutes les données sont reçues par le client.

Si j'envoie un message plus long, en fonction de la longueur du message, un octet est perdu à la fin de chaque paquet. Cela signifie que si j'envoie un message plus long, je devrais ajuster cela en supposant que ce sera toujours le même ou en incluant une balise quelconque pour m'aider à trouver le décalage des données dans le message.

Je pensais qu'il devrait y avoir une meilleure solution.

1

Ce problème a été corrigé. Le serveur TCP/IP utilisait un modificateur de fonction WRITE qui finissait par définir le bit URG dans les paquets TCP/IP. Je crois que le serveur a broyé ceci et différents clients de Windows ont eu une série de problèmes manipulant ces paquets.

Questions connexes