[RESOLVED] Help with VB6 Network coding! Doesn't go in correct order!

Ok I've been using this coding for awhile, the deeper I got into it I realized that it doesn't do everything in order.

VB Code:

Private Sub WStcpClient_DataArrival(ByVal bytesTotal As Long)
    Static sBuffer As String
    Dim Data As String, DataArray() As String, ComArray() As String
    Dim i As Integer, j As Integer, ComI As Integer
    'Get the data from WinSock, Seperate Packets and add each packet (A Command) to the Command Array
    WStcpClient.GetData Data
    Data = sBuffer & Data
    ComArray = Split(Data, packetDelimiter)
    'Save the stuff to carry over to the next event
    sBuffer = ComArray(UBound(ComArray))
    'Loop Through All Commands (Packets) Recieved
    'The last entry is incomplete or "" so ignore it
    For ComI = 0 To UBound(ComArray) - 1
    'Error Handle, If No Data then go to next
        If ComArray(ComI) <> "" Then
            'Stop Loop Hogging resources
            DoEvents
            MsgBox ComArray(ComI) 'VIEW INPUT DATA FOR DEBUG
            'Now Split the current command (Packet) into the Data Array (Array Of Variables unique to the command code
            ' (The command code is in place Zero of the array and is a two letter code telling the client what command to
            ' process, the remaining places are variables needed to do the command )
            DataArray = Split(ComArray(ComI), packetDelimiter)
            '####Data in Data Array Is Proccesed here####
            Call ProcessData(ComArray(), ComI)
        End If
    Next ComI
End Sub

Generally it will process it after wards. but lets say it recieves three things to display in a textbox all at once, but sent out are these:

"1"
"2"
"3"

when you put the debugger on you see it in order, but when it finishes processing in the textbox/etc you will see it in the order backwards more or less, generally what would be displayed is

"3"
"2"
"1"

This only happens when the coding is sent quicker. Can anyone tell why? I found this out when the NPC was attacking before entering the room, generally when I put the debugger on, you'd see the enter room message being first, then the attacks, but since it was all together, it ended up attacking first then you'd see him enter the room.

What it seems like more or less it processes the last thing it gets first.. Not sure what to do.

Also if someone has sample coding that allows correct sending of data,
I can't understand why it displays the last coding it recieves first before the rest (GEnerally if they all got there at the same time)

perhaps showing us how you're sending the data may reflect on the issue at hand.

VB Code:

Public Sub Ostats(ByVal Index As Integer)
    If frmServer.WStcpServer(Index).State <> sckClosed Then
        MsgSend = "~g" & "Welcome to Future Galaxy! There are ~w" & usersonline & "~g users connected and a total of ~w" & userstotal & "~g connections today."
        blnRetVal = WinsockSend(frmServer.WStcpServer(Index), MsgSend)
    End If
End Sub
 
'Load character room for the first time
Public Sub CharacterWelcome(ByVal Index As Integer)
    Dim i As Integer
    
    If Not rsuserdata.EOF Then rsuserdata.MoveFirst ' make sure your on the first one
    rsuserdata.FindFirst "Character='" & users(Index) & "'" 'Find the username
    userroom(Index) = roomidnumber(userroom(Index)) 'Room Number
    Call Ostats(Index)
    
    'If joining the game say this
    For i = frmServer.WStcpServer.LBound + 1 To frmServer.WStcpServer.UBound
    If frmServer.WStcpServer(i).State <> sckClosed Then
        If userroom(i) = userroom(Index) Then 'In the room
            If Not users(i) = users(Index) Then 'User typed
                MsgSend = "~g" & users(Index) & " has just entered the game!"
                blnRetVal = WinsockSend(frmServer.WStcpServer(i), MsgSend)
            End If
        End If
    End If
    Next
    
    Call CheckRoom(Index)
    Call CharacterRoomA(Index)
End Sub

Generally the CharacterWelcome goes first. It will call ostats though. Generally CaracaterRoomA is where it sends more data, it sends this after getting some quick data:

VB Code:

If firstchar = 1 Then
            If frmServer.WStcpServer(Index).State <> sckClosed Then
                MsgSend = "¿csdl¶" & Sidelist
                blnRetVal = WinsockSend(frmServer.WStcpServer(Index), MsgSend)
                MsgSend = "~w<~g" & roomtitle(userroom(Index)) & "~w> " & roomdescription(userroom(Index)) & " " & Charsinroom & " is here with you. There is a " & LCase(itemsinroom) & " here."
                blnRetVal = WinsockSend(frmServer.WStcpServer(Index), MsgSend)
            End If

What happens there is it sends the room data right after the Ostats to the player that joins.

Oh, and WinsockSend is how it sends it:

VB Code:

Public Function WinsockSend(pSock As Winsock, ByVal Data As String) As Boolean
  ' send the data on the passed winsock
  If pSock.State = sckConnected Then
    ' send the data and return true
    pSock.SendData Data & packetDelimiter
    DoEvents
    WinsockSend = True
  Else
    ' return false because we're not connected
    WinsockSend = False
  End If
End Function

The packetdelim is 'packetDelimiter = Chr$(0)'

---

This is what it looks like in a text box (SAMPLE) on connect:

Welcome to Future Galaxy! There are 1 users connected and a total of 1 connections today.
<Dark Room> You are in a dark room. You can see faint light coming from a door to the south.

But sometimes it will do this, this is for any data, but this is a sample. Again this would be on connect.

<Dark Room> You are in a dark room. You can see faint light coming from a door to the south.
Welcome to Future Galaxy! There are 1 users connected and a total of 1 connections today.

As you see it will basicly jump around depending if it was sent to quickly. I don't lose any data, but it seems like its placing the last data recieved on first if two data are send together quickly.

P.S. Ignore the ~w, ~g, etc. Those are for color sending.

This happens with any coding, but thats a sample. Generally whats happening is if two coding is sent out at the same time, the last one is displayed first. It should display the FIRST one always and go down the list.

Bringing this out the grave again because I still cannot figure it out!

Does anyone have any network coding that I could take a look at that handles multiple clients?

This might help.

It isn't perfect but it does address a lot of the common mistakes people make in TCP Winsock control programs. In particular it addresses "the packet fallacy" common to a lot of TCP programs. Remember, a TCP application does NOT have some sort of "packet" interface to the wire, it's a stream. That's the whole point of TCP! You are reading and writing streams, NOT packets.

This sort of "leet speak" leads a lot of programmers astray.

See item 20 in The Lame List.

What you want to send and receive are called frames or messages, not packets.

Thank you very much, read up on that site :P

Thanks for the example as well. I was taught packets, thats why I say it. But glad you corrected me. Seems better that way.. :P

Quote:

---

Originally Posted by Valleriani

Thank you very much, read up on that site :P

Thanks for the example as well. I was taught packets, thats why I say it. But glad you corrected me. Seems better that way.. :P

---

Did this fix your issue or do you still have questions/problems?

In the first post sBuffer was a single Static String that was serving for all connections. This flaw was made much worse by the use of DoEvents() in the DataArrival event handler of course, but was a problem nonetheless.

The sample code in the ZIP archive I posted corrects this without changing the "style" of the program's buffer handling too much. It uses a String array of buffers, one per connection.

Do people realize what DoEvents() really does? I wonder. If so they'd be loathe to ever use it in Winsock control programs. A lot of programmers are already in a trance trying to cope with concurrency without adding this Joker to the deck. I suspect its presence is often a desperation measure when nothing else seems to work.

There are places for DoEvents(), but this just isn't one of them. Here it allows DataArrival for Connection 3 to be interrupted by DataArrival for Connection 7 (or whatever), and on and on, jamming everyone's input into the same sBuffer, etc. It can also lead to a stack overflow if you have several connections or a lot of data arriving. DoEvents() isn't a pause (or much of one). It simply calls the Form's Windows Message Loop once and then gives up its processor slice, like doing a Sleep(0) call, and then returns the oprn Forms count (which most people discard, calling it as if it were a Sub instead of a Function).


If studying the sample didn't help enough perhaps this explanation will shed a little more light.

Yes hack think its all good now.

Thank you for the sample and the explanation. I'll definatly be fixing the coding soon and wiping the DoEvents clean out.