project/Network

Introduction

The following document is the (still incomplete) specification for the design and future implementation of Network in OpenKore.

Note: actual implementation may change and names may vary.

Problems in current Network design

• The serverType specific code is bad.
• Querying for packetID in the code to determine how to unpack is bad.
• The xkore's are hacked in.
• The send part's subs all have their own pack strings and similar code.
• The (un)packing of nested structure type packets is not supported. (handlers need to preform additional unpacking)
• The packet structures are not shared between different serverTypes. (serverTypes must define packets from scratch)
• ...

Network tables

From tables to serverType object

Beyond this i will use kRO as the serverType name.

#	Action	Description	Example
0	read from file:	PACKET LIBRARY (tables)	tables/PACKET_HANDLE_STRUCT.txt
1	store all (un)pack obj to:	PACKET LIBRARY (kore)
2	read from config:	SERVERTYPE[_COMPILEDATE] (user selected)	kRO_2010-05-11aRagexeRE
3	read from file:	PACKET ID HANDLE	tables/kRO/PACKET_ID_HANDLE.txt from top till [2010-05-11aRagexeRE]
4	read from file:	PACKET IMPLEMENTATION	tables/kRO/PACKET_IMPLEMENTATION.txt from top till [2010-05-11aRagexeRE]
5	pick (un)pack obj from:	PACKET LIBRARY (kore) using PACKET IMPLEMENTATION
6	create a serverType obj:	(see 5)

tables/PACKET_HANDLE_STRUCT.txt

description:

• contains all existing packet STRUCT's identified by their respective HANDLE's

notes:

• shared with all ST
• packet lengths can be derived from STRUCT's (can be used in combination with PACKET_ID_LENGTH.txt to do checking or to find serverType)

caveats:

• needs preprocessor directives (see PACKET_IMPLEMENTATION.txt caveat 2.2)

example:

struct EQUIPSLOTINFO {
	/* this+0x0 */ unsigned short info[4];
}
#ifndef EQUIPMENTITEM_EXTRAINFO3
	// older (default to this, if EQUIPMENTITEM_EXTRAINFO3 was not defined) 
	struct EQUIPMENTITEM_EXTRAINFO3 {
		/* this+0x0 */ short index;
		/* this+0x2 */ unsigned short ITID;
		/* this+0x4 */ unsigned char type;
		/* this+0x5 */ bool IsIdentified;
		/* this+0x6 */ unsigned short location;
		/* this+0x8 */ unsigned short WearState;
		/* this+0xa */ bool IsDamaged;
		/* this+0xb */ unsigned char RefiningLevel;
		/* this+0xc */ struct EQUIPSLOTINFO slot;
		/* this+0x14 */ long HireExpireDate;
		/* this+0x18 */ unsigned short bindOnEquipType;
	}
#elif EQUIPMENTITEM_EXTRAINFO3 == 1
	// newer (pick if condition is fulfilled)
	struct EQUIPMENTITEM_EXTRAINFO3 {
		/* this+0x0 */ short index;
		/* this+0x2 */ unsigned short ITID;
		/* this+0x4 */ unsigned char type;
		/* this+0x5 */ bool IsIdentified;
		/* this+0x6 */ unsigned short location;
		/* this+0x8 */ unsigned short WearState;
		/* this+0xa */ bool IsDamaged;
		/* this+0xb */ unsigned char RefiningLevel;
		/* this+0xc */ struct EQUIPSLOTINFO slot;
		/* this+0x14 */ long HireExpireDate;
		/* this+0x18 */ unsigned short bindOnEquipType;
		/* this+0x20 */ unsigned short addedField;
	}
#endif

tables/kRO/PACKET_IMPLEMENTATION.txt

description:

• dictates kore which packets to use from the (PACKET_HANDLE_STRUCT.txt) packet library

notes:

• ST specific
• is (if wanted) sectioned up in compile|distribution-dates so it is possible to support ST's like eA
• packetFUNCTION is what will be used in kore's code

caveats:

1. new packets (new HANDLE, FUNCTION) can get added over time
   1. STRUCT ????, HANDLE ???? => solved by: adding the packetHANDLE and packetFUNCTION (need last one too?)
2. old packets when we look at FUNCTION can change in (STRUCT and HANDLE) are 2 situations:
   1. STRUCT diff, HANDLE same => solved by: encapsulation the different packet's versions in (#if packetHANDLE == X) in the (PACKET_HANDLE_STRUCT.txt) packet library and #define's in ~
   2. STRUCT ????, HANDLE diff => solved by: linking packetHANDLE and packetFUNCTION
   3. a combination of 1) and 2) => solved by: first 1) (filter out by defines) then 2) (assign FUNCTION)

structure:

[RGZ_NAME]
	#define PACKET_HANDLE 1			// solves 2.1
	packetHANDLE packetFUNCTION		// solves 2.2
[END]

example:

[2010-05-11aRagexeRE]						// from 2010-05-11aRagexeRE.rgz
	#define EQUIPMENTITEM_EXTRAINFO3 1
	EQUIPMENTITEM_EXTRAINFO3 EQUIPMENTITEM_EXTRAINFO
[END]								// after this follows kRO (non eA) specific stuff

tables/kRO/PACKET_ID_HANDLE.txt

description:

• links packetID's to packetHANDLE's

notes:

• ST specific
• is (if wanted) sectioned up in compile|distribution-dates so it is possible to support ST's like eA

structure:

typedef enum <unnamed-tag> {
	...
	packetHANDLE =  packetID,
	...
} <unnamed-tag>;

example:

typedef enum <unnamed-tag> {
	...
	HEADER_CZ_PARTY_BOOKING_REQ_SEARCH =  0x804,
	...
} <unnamed-tag>;

tables/kRO/PACKET_ID_LENGTH.txt

description:

• contains all existing packet lengths identified by their respective ID's

notes:

• ST specific
• replaces recvpackets.txt (the name makes no sense, the file contains the length of sent packets as well)
• is redundant, the packetlength can be derived from the structs in (PACKET_HANDLE_STRUCT.txt)