another quick question

[tA-Kane]

Here's the VB-ish code (since I don't use VB, I don't know how accurate it is) for how my lagbuffering works...

Code Select Expand

BnetGameSocket.LagBuffer As String

Event BnetGameSocket.DataAvailable()
 Me.ReadData(Me.ReadAll)
End Event

Sub BnetGameSocket.ReadData(Data As String)
 Dim PacketData As String
 Dim PacketDataLen As Integer, PacketID As Integer
  
 'New data gets appended to the lag buffer below
 Me.LagBuffer = Me.LagBuffer & Data
  
 Do
  If LenB(Me.LagBuffer) < 4 Then
   'Received data length is less then minimum packet length (0xff & id & length)
   Exit
  End If
  'StringToInteger is a custom function which
  'converts binary string data to an integer
  '(similar to Val(), but base 256 instead of base 10)
  PacketID = AscB(MidB(Me.LagBuffer,2,1))
  PacketDataLen = StringToInteger(MidB(Me.LagBuffer,3,2))
  'Remove header length from packet length to get data length
  PacketDataLen = PacketDataLen-4
  If PacketDataLen < 0 Then
   'Cannot have less than 0 datalength
   Me.Close
   Exit
  ElseIf PacketDataLen < LenB(Me.LagBuffer) Then
   'LagBuffer does not contain the whole packet
   Exit
  End If
  'get packet data
  PacketData = MidB(Me.LagBuffer,5,PacketDataLen-4)
  'send packet to the method which calls the appropriate packet handler, based on PacketID
  Me.PacketReceived(PacketID,PacketData)
  'remove packet from the lag buffer
  '(location of next packet data is 1+(PacketLen))
  Me.LagBuffer = MidB(Me.LagBuffer,1+PacketDataLen+4)
 Loop
End Sub


The reason I call ReadData() instead of just having the ReadData() code in .DataAvailable event, is so that I can test my socket without actually connecting to Battle.net, by calling ReadData() from a different source (such as a test window).

[Camel]

Hmm, alright...
What if you receive an entire packet 1 byte at a time?

it'll work fine
peekdata doesnt remove anything from the buffer. only getdata does that. it'll keep grabbing the first 4 bytes with peekdata until the ammount of data in the buffer is at least the size of the packet, and then get the entire packet

but just on a side note, it's pretty safe to assume that such a thing will never happen

[edit] you could also use getdata and declare the variable using "static" instead of "dim". that way it would retain the packet length from one _dataarrival to the next.

[Yoni]

but just on a side note, it's pretty safe to assume that such a thing will never happen

Not really.
Maybe on real Battle.net it won't happen, since it's configured for optimal efficiency.
But one could make a fake server that is evil and sends packets 1 byte at a time on purpose.

[Camel]

or, one could not...

[tA-Kane]

or, one could not...

It wouldn't be hard to put all data-to-be-sent into a buffer, and then create a timer that activates once every, say..., 100ms, which sends then removes the first byte in the buffer, OR, if the buffer is empty, then it does nothing.

[Skywing]

it'll work fine
peekdata doesnt remove anything from the buffer. only getdata does that. it'll keep grabbing the first 4 bytes with peekdata until the ammount of data in the buffer is at least the size of the packet, and then get the entire packet

but just on a side note, it's pretty safe to assume that such a thing will never happen

[edit] you could also use getdata and declare the variable using "static" instead of "dim". that way it would retain the packet length from one _dataarrival to the next.

Split packets *are* common on Battle.net - ever joined a nearly-full channel?

[iago]

Split packets *are* common on Battle.net - ever joined a nearly-full channel?

Yes, that used to always crash my plugin

[Camel]

Split packets *are* common on Battle.net - ever joined a nearly-full channel?

i was referring to packets that are <4 bytes (eg, the first two bytes of the bnet packet header)

[Skywing]

i was referring to packets that are <4 bytes (eg, the first two bytes of the bnet packet header)

Yes.  The most likely time for this to happen is when packets are split -- such as, say, part of a header in one TCP packet and part in the next.