Bypassing the Winsock receve buffer?

[Tontow]

How would you go about bypassing Winsock's receve buffer?

edit: I want to do this because Winsock's current receve buffer dosn't fit my needs and I don't want to have to double buffer my data.

[MyndFyre]

A Winsock OCX control or the Windows Winsock API?

[Tontow]

I'm useing the OCX control.

The problem is: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mswnsk98/html/vbmthgetdatawinsock.asp

It's common to use the GetData method with the DataArrival event, which includes the totalBytes argument. If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 indicating that the remaining bytes will be lost.

I need to bypass or replace Winsock's receve buffer because I want to specify a maxlen that is less than the totalBytes argument without loseing the remaining bytes.  If I could at least substitute or replace the GetData Method, then the rest of Winsock's current buffer might sute my needs.

[MyndFyre]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsarecv_2.asp

(This might work better)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/recv_2.asp

[R.a.B.B.i.T]

I'm useing the OCX control.

The problem is: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mswnsk98/html/vbmthgetdatawinsock.asp

It's common to use the GetData method with the DataArrival event, which includes the totalBytes argument. If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 indicating that the remaining bytes will be lost.

I need to bypass or replace Winsock's receve buffer because I want to specify a maxlen that is less than the totalBytes argument without loseing the remaining bytes.  If I could at least substitute or replace the GetData Method, then the rest of Winsock's current buffer might sute my needs.

Don't specify the option max length?

[Tontow]

You missed my objective; I'm trying to eliminate the need for a secondary packet buffer. 

I'm testing the assumption that grabbing a single individual packet directly from the buffer would be better than using a secondary buffer to separate the packets.

I don't know if anyone has tryed doing this befor...

[R.a.B.B.i.T]

When you receive(wtf I can't spell that?) data from a winsock and store it into a data buffer, there is only 1 buffer.  Winsock is not a buffer.  When data arrives, you either take it or you don't.  If you don't, it gets overridden.  If you take SOME of it, what you take you store, and again, everything is overridden.

[Eric]

When you receive(wtf I can't spell that?) data from a winsock and store it into a data buffer, there is only 1 buffer.  Winsock is not a buffer.  When data arrives, you either take it or you don't.  If you don't, it gets overridden.  If you take SOME of it, what you take you store, and again, everything is overridden.

... Winsock buffer's all data until it has been read.

[Eric]

You missed my objective; I'm trying to eliminate the need for a secondary packet buffer. 

I'm testing the assumption that grabbing a single individual packet directly from the buffer would be better than using a secondary buffer to separate the packets.

I don't know if anyone has tryed doing this befor...

You can use the Winsock control's PeekData() function to "peek" at the packet's data to determine the packet's length and then use the GetData() function with the length of the packet set as the maximum length to read and remove the data from Winsock's buffer.

Since you don't have direct access to Winsock's buffer, you'll have to pass Winsock a reference to a buffer which you've created therefore your idea won't work.  You have to have your own "secondary" buffer.

[Adron]

... Winsock buffer's all data until it has been read.

From looking at the winsock ocx, I think it's actually already double buffering the data. I think the winsock ocx calls winsock to recv into a temporary buffer before the DataArrival event is triggered. The data having been copied into a temporary buffer for the duration of the event notification is the only explanation I can find for why it'd be lost if you call GetData to read less than the whole amount of data.

[Tontow]

You missed my objective; I'm trying to eliminate the need for a secondary packet buffer. 

I'm testing the assumption that grabbing a single individual packet directly from the buffer would be better than using a secondary buffer to separate the packets.

I don't know if anyone has tryed doing this befor...

You can use the Winsock control's PeekData() function to "peek" at the packet's data to determine the packet's length and then use the GetData() function with the length of the packet set as the maximum length to read and remove the data from Winsock's buffer.

Since you don't have direct access to Winsock's buffer, you'll have to pass Winsock a reference to a buffer which you've created therefore your idea won't work.  You have to have your own "secondary" buffer.

Well, it would work, but GetData clears the buffer, or more precisely the input queue, every time its used and that's why I need to replace GetData in order to avoid adding another buffer. 

If we only had the sourcecode for the Winsock control...........

[Eric]

... Winsock buffer's all data until it has been read.

From looking at the winsock ocx, I think it's actually already double buffering the data. I think the winsock ocx calls winsock to recv into a temporary buffer before the DataArrival event is triggered. The data having been copied into a temporary buffer for the duration of the event notification is the only explanation I can find for why it'd be lost if you call GetData to read less than the whole amount of data.

... They have it wrong; my guess is that they were using GetData() when they should have been using PeekData() and/or they were expecting DataArrival() to be repeatidly called until the buffer was empty.  The data is not removed from the buffer until it has been read.

Just to verify this, I had my DataArrival() function set to only read 1 byte of data from the buffer and had a timer set to 2.5 seconds read the remaining data, byte by byte.

Code Select Expand

Private Sub sckBNCS_DataArrival(index As Integer, ByVal BytesTotal As Long)
    Dim strBuf As String
   
    sckBNCS(index).GetData strBuf, vbString, 1

    Call modGlobals.clsBot(index).clsBNCS.PreParse(strBuf, 1)
End Sub

Code Select Expand

Private Sub Timer1_Timer()
    Dim strBuf As String

    Do:
        sckBNCS(0).GetData strBuf, vbString, 1

        Call modGlobals.clsBot(0).clsBNCS.PreParse(strBuf, 1)
    Loop Until (strBuf = vbNullString)
End Sub

[09:18:25] Basic Battle.net Binary Bot v2.00 Beta Build: 346
[09:18:25] Copyright (C) 2005 Eric Evans
[09:18:27] Connecting to Battle.net game server...
[09:18:27] Connected to Battle.net game server; negotiating...
[09:18:28] IX86ver2.mpq requires an update; downloading...
[09:18:36] Successfully entered chat environment as: LoRd[nK]

Little on the slow side, but other than that, it works fine.

You missed my objective; I'm trying to eliminate the need for a secondary packet buffer. 

I'm testing the assumption that grabbing a single individual packet directly from the buffer would be better than using a secondary buffer to separate the packets.

I don't know if anyone has tryed doing this befor...

You can use the Winsock control's PeekData() function to "peek" at the packet's data to determine the packet's length and then use the GetData() function with the length of the packet set as the maximum length to read and remove the data from Winsock's buffer.

Since you don't have direct access to Winsock's buffer, you'll have to pass Winsock a reference to a buffer which you've created therefore your idea won't work.  You have to have your own "secondary" buffer.

Well, it would work

This idea will still not work.  You'll have to have your own secondary, or as Adron pointed out, third buffer (strBuf) in order to read data from Winsock and since you don't have direct access to Winsock's buffer (as I said before), you'll have to rely on PeekData() to store the contents of the Winsock buffer into your own to determine the packet's size and then GetData() to actually read and remove the data from the buffer, so not only will this idea create a third buffer, it will be reading the same data twice thus making it slower and less efficient than storing all incoming data into your own buffer and then handling the packets from it.

[MyndFyre]

...all of which circumlocutes that, if you don't want to have to use extra buffers from the Winsock control, the Winsock API might be the way to go. 

[Eric]

...all of which circumlocutes that, if you don't want to have to use extra buffers from the Winsock control, the Winsock API might be the way to go. 

You'd still have to pass recv() a reference to a buffer which you've created, a secondary buffer, and you'd still have to call recv() with MSG_PEEK to determine the packet's length and then again to actually read and remove the data...

[Warrior]

down lord down.