WideServer SDK

[cknipe]

Hi Pete,

Any chances perhaps of a WideServer SDK type of document? Nothing definate yet, but I might want to access WideServer from another OS and not Windows...

Would be extremely nice if it would be possible. Will understand if not :)

--

Chris

[Pete Dowson]

Any chances perhaps of a WideServer SDK type of document? Nothing definate yet, but I might want to access WideServer from another OS and not Windows...

Would be extremely nice if it would be possible. Will understand if not :)

--

Chris

There's no chance at present. I just don't have time to do the documentation (for that's all there would be). Sorry.

Last time someone did this for an Apple or Linux PC was years ago, and he just analysed the data streams and asked the odd question now and then. Things have changed a bit though since then.

Regards,

Pete

[cknipe]

Will bring in the ol' ethernet packet dumper and see what I can come up with them. Shouldn't be to hard unless you're using some form of encryption and the like, which I doubt. :)

As long as there's no violations in regards to licensing and the like, I guess, I am allowed to do this right?

Thanks Pete,

Chris.

[Pete Dowson]

Will bring in the ol' ethernet packet dumper and see what I can come up with them. Shouldn't be to hard unless you're using some form of encryption and the like, which I doubt. :)

No encryption, but a very simple compression is used -- replacing multiple copies of the same value by a count, with a special escape value. Don't remember what it is though. Maybe hex AA.

You can use "Log=DebugAll" in WideClient to log almost everything and see the data as it has been received and how it expands. Should help. The logs can get pretty big quite fast, mind.

Regards,

Pete

[cknipe]

Hi Pete,

I see what you meant in some rather ancient posts about this. It's not really worth the effort :(

Did have a look at the DebugAll logs, but ja... Didn't make me any wiser. The contents of the TCP packets are definately there, but as to what it is actually sending / receiving in layman's terms... Urgh.

For one, the debug log only indicates (for example), Requesting offset xyz. It never actually logs *how* it requests it (i.e. what is sent to wide server). Then it receives the packet on the Ethernet, and it shows the packet dump of the data it has received. Same goes for DebugAll on WideServer...

I guess I'm kinda hoping to a more 'communications' orientated log, i.e.

Client -> Server: this is how I request offset xyz

Server -> Client: offset xyz = whatever

I won't know whether this is possible or feasable for you, but you can't perhaps include a TX and RX dump? Some other detailed logging on what it is receiving / transmitting other than the actual packet, might be usefull as well. If that's not possible, I'm definately not going to fiddle with this - will take ages to figure this out.

I guess, as you said in previous posts about this topic, the most feasable way to accomplish this would be to simply write your own module for FS9, and have your remote OS talk to the module, rather than WideFS... That might also actually be *allot* easier I reckon...

Thanks for the input Pete. Much appreciated :)

--

Chris.

[Pete Dowson]

For one, the debug log only indicates (for example), Requesting offset xyz. It never actually logs *how* it requests it (i.e. what is sent to wide server). Then it receives the packet on the Ethernet, and it shows the packet dump of the data it has received. Same goes for DebugAll on WideServer...

The requests basically follow the same format as the requests put directly to FSUIPC, as defined in the .h header files in the sources for the libraries in the C parts of the FSUIPC SDK. They used to be identical, in fact, but I decided that was a waste of space (Adam Szofran used whole DWORDs for things only needed a byte or word, for example). Also I extended the command set.

The blocks are easy to decode once you realise the structure if the FS6IPC structure , or derived from it.

The codes used at present are as follows:

// IPC message types
#define FS6IPC_READSTATEDATA_ID    1
#define FS6IPC_READSTATEDATA_ID_NEW    0xfe
#define FS6IPC_READSTATEDATA_ID_SHORT  0x1001
#define FS6IPC_READSTATEDATA_ID_NEWSHORT  0x3001
#define FS6IPC_READSTATEDATA_ID_NEWNEWSHORT  0x7001
#define FS6IPC_READSTATEDATA_ID_COMP  3
#define FS6IPC_READSTATEDATA_ID_NEWCOMP  0xfc
#define FS6IPC_WRITESTATEDATA_ID   2
#define FS6IPC_SPECIALREQUEST_ID   0xabac
#define FSUIPC_COMPUTER_NAME_ID   0x1002
#define FSUIPC_EXTRA_DATA_ID	  0xed

Some structures new in WideFS compared to FSxIPC are:

// read request structure
typedef struct tagFSUIPC_SHORTREAD_HDR
{ union {
	DWORD dwOffset;   // state table offset, high byte = ID
	BYTE bBytes[4];
	} Id;
  WORD sBytes;     // number of bytes of state data to read
} FSUIPC_SHORTREAD_HDR;

// write computer name structure
typedef struct tagFSUIPC_COMPUTER_NAME_HDR
{
  DWORD dwId;       // FSUIPC_COMPUTER_NAME_ID
  DWORD nBytes;     // number of bytes in name string following
} FSUIPC_COMPUTER_NAME_HDR;

There are probably others, but I'd have to ferret them out. They should be easy enough to follow given all this though.

I won't know whether this is possible or feasable for you, but you can't perhaps include a TX and RX dump?

That's there already. Aren't you seeing it? The DebugAll logging includes pretty much everything, there are separate options.

Pete

[Pete Dowson]

Further to the details in my last message, you should note that, like IPC transfers direct with FSxIPC the blocks defining particular read, write or other operations are themselves blocked together in frames, up to 30kb in size (though limited by parameters in the INI normally).

With IPC transfers these blocked requests do not have a header, but simply a zero DWORD terminator. In WideFS transfers yjrtr#s no terminator, but each frame (blocks of requests) has a header which contains the block size, a sumcheck and a sequence number or timestamp.

The WideFS logs actually do not log the header in raw bytes but decode it and show the walues at the head of each frame decode. I thought you'd see that immediately if you were monitoring the actual TCP/IP data being transferred, but if not here is the frame header format:

struct
{  ULONG ulSize;
   ULONG ulTime;
   WORD  uSum;
   BYTE fUsed;
} PREQHDR;

Don't ask me what "fUsed" is -- this is a bit historical. I would need to delve deep into code to work that out. The others should be easy enough. The Sumcheck is a byte sumcheck of the data following the header which is of size ulSize. The ulTime values used to be a timestamp but now it is just a sequence counter, at least in the ->client direction (I've not checked the other way).

Well, that's about it. You should be able to go a long way with all that. I can try answering specific questions if you get stuck.

Regards,

Pete