News:

Wieners, Brats, Franks, we've got 'em all.

Main Menu

[JAVA] Packet Joins

Started by Lance, June 21, 2010, 12:37:55 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Lance

Joe brought something interesting up in the JavaOp section:
Quote from: JoeBecause all the packet plugins are loaded by the core, not by the Battle.net plugin, so they'd be getting the raw socket data instead of packets. The only issue with that is that Battle.net is known to send packets in pieces or several packets in one clump, so there'd have to be a non-protocol-agnostic packet thread to pick these apart for parsing, not to mention it's not a good idea to trust TCP connections to have packets split perfectly, even if it's known to in the past.

I am currently working on a program with a (non-bnet) protocol, but have run into this issue. In particular, I have 13000 bytes of data split over a few packets. This is the code I am currently using:

public void run() {
while(true) {
try {
Packet buf = new Packet(); //Packet is just a small extension of iago's Buffer class, similar to BNetPacket in some ways.
int size = new Buffer(PacketTools.getInputStreamBytes(in, 4)).removeDword(); //This reads 4 bytes (packet size) into a new Buffer and converts them into an int
buf.addBytes(PacketTools.getInputStreamBytes(in, size)); //Read "size" number of bytes from the InputStream and add them to the buffer
// Do stuff
} catch (Exception e) {
e.printStackTrace();
return;
}
}
}


How can I change this so I can read multiple packets into that single Packet instance (buf)?

Thanks :)
Quote from: Joe
[23:55:31] [william@enterprise ~/Documents/Programming/javaop2]$ svn commit -m 'Tried to fix StayConnected. Again.'
Committed revision 63.
StayConnected strikes back!

Joe

I'm not sure I understand your code. The only solution I know of to this lies in the Battle.net protocol itself. Consider the packet header:

(INT8) 0xFF
(INT8) Packet ID
(INT16) Packet Length


In this case, we're relying on the packet itself to tell us how much data to read. Consider lines 135 through 147 of the PacketThread class. It reads the first four bytes, checks for various errors, then establishes the length of the packet we're currently working with. It completely ignores anything left after if it's a clump as you're dealing with, or it waits for the remainder if it hasn't arrived yet, as I mentioned in that quote.

TLDR: It depends on the protocol.
Quote from: Camel on June 09, 2009, 04:12:23 PMI'd personally do as Joe suggests

Quote from: AntiVirus on October 19, 2010, 02:36:52 PM
You might be right about that, Joe.


Lance

#2
Looking through PacketThread now! Thanks :)

EDIT: Works like a charm! Thanks! ;D
Quote from: Joe
[23:55:31] [william@enterprise ~/Documents/Programming/javaop2]$ svn commit -m 'Tried to fix StayConnected. Again.'
Committed revision 63.
StayConnected strikes back!