Difference between revisions of "project/Network"

From OpenKore Wiki
Jump to navigation Jump to search
m (initial draft)
 
Line 15: Line 15:
 
==Network tables==
 
==Network tables==
 
===From tables to serverType object===
 
===From tables to serverType object===
Beyond this i will use kRO in the example.
+
Beyond this i will use kRO as the serverType name.
 
:{|border="1" cellpadding="2" cellspacing="1"  
 
:{|border="1" cellpadding="2" cellspacing="1"  
 
|- style=background-color:#F9F9F9;
 
|- style=background-color:#F9F9F9;

Revision as of 20:25, 22 July 2010

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: PACKET LIBRARY (tables) tables/PACKET_HANDLE_STRUCT.txt
1 store all (un)pack obj to: PACKET LIBRARY (kore)
2 read from: SERVERTYPE[_COMPILEDATE] (user selected) kRO_2010-05-11aRagexeRE
3 read from: PACKET ID HANDLE tables/kRO/PACKET_ID_HANDLE.txt from top till [2010-05-11aRagexeRE]
4 read from: 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 1
	packetHANDLE packetFUNCTION		// solves 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)