0
Forum
Our Products
What's New
Our partners
Contact Us
   
   
.: Study Of Transmission Control Protocol :.
By Nicholas Hall


First lets talk about TCP, It is a Stream Oriented Protocol! Not a Message Based Protocol! The difference is being, TCP 
is used to send Data reliably but even more so it combines multiple messages in a big long never ending train until all 
the information gets there, unlike UDP, a Message Based Protocol, It sends all the Data one Message at the time so no 
additional parsing is required for the works of layer 5,6,7 to separate clumped messages.

This is code that I love to use as an example on how to handle Data with TCP, Now this only is useful in a situation that 
involves sending ASCII text such as "Hello World!". The reason why is due you the way this code works is it looks for a 
Terminating char in this case 'Chr(255)' to know that the end of the message has been recv'ed.

vb6
[code]Private Sub FileManagerSocket_DataArrival(ByVal Index As Variant, ByVal bytesTotal As Long)
    FileManagerSocket.GetData Index, Data, vbString
    'Data
    'Data EOF
    'Data EOF Data
    'Data EOF Data EOF
    'EOF Data
    'EOF Data EOF
    'EOF Data EOF Data
    'EOF
    'Must Write Code To Wrap All These Cases
    If InStr(Data, Chr(255)) = bytesTotal Then
            M_FileManager.HandleData Index, FileManagerSocketBuffer & Left$(Data, Len(Data) - 1), vbString  'Take Off The EOT
            FileManagerSocketBuffer = vbNullString
        ElseIf InStr(Data, Chr(255)) = 0 Then
            FileManagerSocketBuffer = FileManagerSocketBuffer & Data
            Debug.Print "Got Chunk Of Message"
        Else
            Dim ParseMsg() As String
            ParseMsg = Split(Data, Chr(255))
            
            For i = 0 To UBound(ParseMsg) - 1
            
            M_FileManager.HandleData Index, FileManagerSocketBuffer & ParseMsg(i), vbString  'Take Off The EOT
            FileManagerSocketBuffer = vbNullString
            
            Next
            
            FileManagerSocketBuffer = ParseMsg(i + 1) 'Store Last incomplete Chunk in the buffer
            Debug.Print "Got Full Message Plus Extra For Next Message"
    End If
    Debug.Print Replace(Data, Chr(255), "(EOT)")
End Sub[/code]



As you can see the following Data Arrival events are possible Data Data EOF Data EOF Data Data EOF Data EOF EOF Data EOF Data EOF EOF Data EOF Data EOF seeing you can get Multiple Messages at once or Multiple Messages + Chunks of another incoming message, Use a Global buffer to store the last Chunk before you exit the DataArrival Functions and lose the Data, FileManagerSocketBuffer being my Public Var! Now on the other hand when sending Binaries such as Files or just Raw Data in Memory sometimes they may contain the Delimiter which in the last case was 'Chr(255)' and that would then throw off our message making Data incomplete and worse comes to worse and our application is not programed to handle our exception it may crash out program! So there are several ways to go upon this, but I personally only use two method's you can decided whats better for you in your situation and go from there. Method 1: Create Two Sockets, Make one Send the Data containing information about the File Such as the Size and all the goodies like name then have your other one in another thread go into a while loop sending the file in Chunks of anywhere i'de say from 1024 Bytes to 8192. Pro's: While the socket is sending you can still send other commands to the recv'er at the same time giving the fact you have two sockets involved which is great for a file Manager so you can browse a Directory tree and transfer a file at the same time!. Con's: Uses Two sockets, This is hardly an issue for most of us really! Method 2: Send the Length of the Message before hand! Telling the other side saying wait for 20 bytes to come through is a great way to have the Recv'er know when you chop off the end of the recv'ing Data and to act on it. For this method I recommend at least four bytes at the start of every message due to the possibility that the binary could be up to 4 Gigs of information anything less then four bytes such as three can only wait for 16MB of Information and two bytes up to 64k, which is not good enough to hold all types of files that we use everyday! Pro's Simple and Reliable. Con's If you find that the program you are using sends only Single Hex values such as 0x01 etc etc you find after packing the information that you really are sending five bytes in the end making your message Huge compared to using method one which only uses two byte's, Remember both method's can out perform one another and is best to figure out which one best matches your needs!
 

.: Links :.

Forums
Desert Computer Agents



Website Homepage | About Us | Forums | Our Products | What's New | Our Partners | Contact Us
Cubicle Generation | Arguments Callee | Desert Defenders
Web site contents Copyright Controlling The Internet 2007, All rights reserved.