[code][/code]After I added proxy support to my program (to run more than 8 bots), Ive been recieving partial packets from battle.net.

Ive fixed this problem by placing this into my dataarrival:
[code]
On Error Goto lngWait
lngWait:
Exit Sub
[/code]
and making strBuffer an array for each bot....
But I dont like these quick debug fixes, I prefer to solve the problem rather than going around it.

Do socks proxies send partial packets more frequently?

I believe this fix only works because my program exits the sub when it recieves a partial packet (hence, an error occurs) and waits for rest of the packet to arrive.

I can see that my lngLen is returning negative values. Is there anyone that has a more practical fix?

[Visual Basic]

[quote author=Lenny link=board=17;threadid=4050;start=0#msg33465 date=1070485209]
Is there anyone that has a more practical fix?[/quote]

Yes. Stop loading so many bots.

Aside from running 8 bots, this post has nothing to do with Battle.net programming. It belongs on the VB or General Programming forum.

Well, bot developers would have the most use for this and bot developers would have the highest probability of having the solution to this problem

Well, I'de rather load so many bots than avoid the problem completely.

[quote author=Lenny link=board=17;threadid=4050;start=0#msg33478 date=1070487296]
Well, bot developers would have the most use for this and bot developers would have the highest probability of having the solution to this problem

Well, I'de(sic) rather load so many bots than avoid the problem completely.
[/quote]

I hardly see that this has nearly any relevance to bot development unless you're trying to develop a loader bot. I also think that a general internet programmer, particularly one who has developed a proxy server or firewall for general use, would be more likely to have the solution than bot programmers. Not everybody sees a lot of use in loading a channel.

If you're looking for sample proxy server code, a quick Google search for "proxy server development" returned the following link within the first 10 hits:

http://www.programmersheaven.com/zone14/cat767/

It might just help you find what you're looking for. Notice that it's at Programmers Heaven.com, not The Disclaimer (botdev.valhallalegends.com).

[quote author=Lenny link=board=17;threadid=4050;start=0#msg33478 date=1070487296]
Well, I'de rather load so many bots than avoid the problem completely.[/quote]

What use could you possibly have for so many bots?

Well, I just wanted to try something new, loading multiple bots seemed like an interesting idea.

[quote author=Lenny link=board=17;threadid=4050;start=0#msg33536 date=1070493567]
Well, I just wanted to try something new, loading multiple bots seemed like an interesting idea.[/quote]

You can get quite a few without any proxies, and barring a good use for them, there's really no reason to tie up (or even have) that many cdkeys.

Yes, Lenny I know what your talking about it. I hate it when that happens it delays a lot and uses a lot of memory on the bot. I had the same problem with my bot which also loaded multiple amount of usernames onto battle.net. It also seems like i get partial amount of data, a lot of the time it disconnects to unknown errors.
I tried debugging it a lot back then but I also forgot a lot because it was a long time ago. Try loading them for one different winsock all at once and send the data to the other bots. Thats my only suggestion for you.

Ew why was my post deleted? Was perfectly helpful...

Sadly, I never got to read the post either...

I'm still trying to find a better way to solve the partial packet problem than the one I posted above.

Also, besides recieving partial packets, does battle.net ever not send the &HFF header? People say it happens occansionaly and other than that the rest of the packet is fine.

I have received packets without the 0xff header; however, my bot disregards them. I don't even bother trying to decode them; if that means a lost chat message, oh well.

[quote author=Myndfyre link=board=17;threadid=4050;start=0#msg33683 date=1070577738]
I have received packets without the 0xff header; however, my bot disregards them. I don't even bother trying to decode them; if that means a lost chat message, oh well.[/quote]

Under what circumstances did this happen? I have a client parked in the vL channel most of every day and don't recall ever receiving a damaged BNCS packet.

On packetlogs, I've received data from BNCS that didn't have the 0xff header.

That isn't to say that the Socket didn't assemble it correctly before it got to me or anything of the sort. However, I can recall at least three instances where I was baffled because Ethereal said the data I got from a BNCS server did not begin with 0xff.

(okay it didn't "say" it - it displayed it).

[quote author=Myndfyre link=board=17;threadid=4050;start=15#msg33716 date=1070582948]
On packetlogs, I've received data from BNCS that didn't have the 0xff header.

That isn't to say that the Socket didn't assemble it correctly before it got to me or anything of the sort. However, I can recall at least three instances where I was baffled because Ethereal said the data I got from a BNCS server did not begin with 0xff.

(okay it didn't "say" it - it displayed it).
[/quote]
It sounds like the data got split into more than one TCP packet. This is normal, as TCP is a stream protocol.

When analyzing tcp streams in Ethereal, you should use the Follow TCP Stream feature on the Tools menu.

Don't look at the individual packets as they are displayed in the bottom pane unless you're interested in debugging incomplete packet sends causing additional RTT delays, TCP disconnections, dropped packets, or something like that.

Like Skywing says, TCP is stream based, and the packets don't matter to TCP, only the stream.

What Skywing and Adron are trying to say, without being obvious is yes, it is indeed possible to receive a partial BNCS packet. But you see, because TCP is a reliable stream, you will receive the rest of the packet (or perhaps even just another part), before receiving the next packet.

Now for a solution to your problem, think of a solution to this logic quiz:

You are expecting 3 BNCS packets.
You receive part of the first packet.
Some time later, you receive another part.
Even later, you receive both the end of the first packet, and the beginning of the second packet, but the number of bytes you receive of the second packet is only two bytes; that is insufficient to know the length of the BNCS packet.
After some time, you receive the end of the second packet.
Lastly, you receive the third packet in whole.


This logic problem is possible both with and without a proxy connection, and it is also possible to parse all three packets in their entirety.

Yes, think of reading from a tcp socket as of reading from a file or anything similar - you can read one byte at a time and there are no packets.

The solution to Kane's problem:
Think of each packet as 2 seperate packets. A header, which is 4 bytes, and the rest, whose length is specified by the header.


Now this got me to thinking: do we really need packetbuffers? I propose that somebody write a bot which,instead of insertDword, insertNTString, etc, just sends the data as the packet is built.

So:
sendByte(0xFF)
sendByte(0x0E)
sendWord(0x09)
sendNTString("Moo!");

[quote author=iago link=board=17;threadid=4050;start=15#msg34012 date=1070751576]
The solution to Kane's problem:
Think of each packet as 2 seperate packets. A header, which is 4 bytes, and the rest, whose length is specified by the header.


Now this got me to thinking: do we really need packetbuffers? I propose that somebody write a bot which,instead of insertDword, insertNTString, etc, just sends the data as the packet is built.

So:
sendByte(0xFF)
sendByte(0x0E)
sendWord(0x09)
sendNTString("Moo!");
[/quote]

You can't always do this becuase the size of the packet may vary depending upon content.

[quote author=warz link=board=17;threadid=4050;start=15#msg34018 date=1070753650]
"dxoigmn**subterranean homesick alien/."

Mind explaining?
[/quote]

dxoigmn**subterranean homesick alien

[quote author=kamakazie link=board=17;threadid=4050;start=15#msg34016 date=1070753289]
You can't always do this becuase the size of the packet may vary depending upon content.[/quote]

Actually, you can send it piece by piece (though this would be much less efficient for everybody involved). You just wouldn't necessarily be able to hardcode the packet length, but it's not that much trouble to compute the length, then send it, then send each of the pieces.

Yes, it would be a great deal less efficient. For functions that operate on variable amounts of data, like send(), it makes much more sense to call them once, with lots of data, than lots of times with little data. The reason being that calling a function incurs some overhead in terms of CPU time. If you call such a function once with 1024 bytes of data, you incur that overhead once. If you call it 4 times with 256 bytes of data, you incur 4 times as much overhead.

The biggest problem is the way tcp works. I'm not sure of the exact workings, but something like this:

If you send 4 bytes, then 2 bytes, then 3 bytes, starting from zero with nothing sent before, the 4 bytes will be sent immediately. After that, the remaining 5 bytes will be held until either a timeout expires, or the first 4 bytes are acknowledged from the other end.

If you on the other hand send 9 bytes right away, they'll all be delivered immediately.

This means that it will take your complete packet another rtt to arrive at the other end if you send it piece by piece.