Gryphon Communication Protocol : Client How-To

Sample Client-Server Session

The following example is mostly language independent, but C functions may be casually referenced at points. The session is described in terms of the data values transmitted between the server and an arbitrary client. First, let's look at our typical session from a fairly high-level view. Once we've had a nice overview we'll get a bit more into detail with the data.

The following tables are an example of the commands, responses, and data that might be sent during a session. Time increases by rows, and columns show the information being sent from the client or server, or an action that each might take.

 

Client	Server	Comments
	[Listening]	Server is up, and ready to take incoming connections
[ connect() ]	[ accepts connection ]	Client initiates a TCP/IP (stream) connection; default port is 7000
Command Frame: CMD_SERVER_REG and data.		As a client, the first thing I'll want to do is "log on" with a username and password.
	Response Frame: RESP_OK , Client ID and permissions in data.	I'm going to hang on to that Client ID, because I'll need to use it for SRC CHANNEL in any frames I transmit for the rest of this session.
Command Frame: CMD_GET_CONFIG		No command data required, just a frame header and a command-frame header
	Response Frame: RESP_OK, lots of configuration data follows	First 64 bytes following the response-header is a record (server config), followed by 80 byte records (channel configs). All data in ASCII.

At this point, the client would parse through the config data, and figure out how many channels/protocols this particular has available. Which channel(s) the client will use is up to your application and needs. Let's say I'd like to record some traffic on a (one) CAN network. After looking at the configuration data, my application tells me that this has CAN protocols on channels 2 and 3. I've connected my CAN network to the module, but I'm not sure if it's on channel 2 or channel 3. I'll simply listen to both with no harm done, since nothing is attached to the 'wrong' channel.

 

Client	Server	Comments
Command Frame: CMD_CARD_SET_FILTER_MODE MODE = FILTER_OFF_PASS_ALL DST CHANNEL: 3 Data is set to a "pass all" filter	[starts forwarding traffic from channel 3]	Nothing connected to this channel, so I get no CAN traffic.
	Response Frame: RESP_OK No data	I'd get this response frame before any data frames. Don't mistake it for protocol traffic.
Command Frame: CMD_CARD_SET_FILTER_MODE MODE = FILTER_OFF_PASS_ALL DST CHANNEL: 2 Data is set to a "pass all" filter	[starts forwarding traffic from channel 2]	This turns out to be the one that's connected.
	Response Frame: RESP_OK No data	Again, I get this response frame before any data frames.

 

Client	Server	Comments
	Data Frame: data contains CAN frame	First Data frame. Server sends these as they occur on the network
	Data Frame: data contains CAN frame	Data frame 2
	Data Frame: data contains CAN frame	Data frame 3
... server sends many more data frames ...
	Data Frame: data contains CAN frame	Data frame (n)
	Data Frame: data contains CAN frame	I decide I've had enough CAN frames, thank you.
Command Frame: CMD_CARD_SET_FILTER_MODE, MODE = FILTER_OFF_BLOCK_ALL DST CHANNEL == 2 Data sets filter to "block all"	Data Frame: data contains CAN frame	So I have my client instruct the server to cease sending them.
	Data Frame: data contains CAN frame	It's possible my client will get a few more while the filter command is being processed. Data frame (n+3)
	Response Frame: RESP_OK	No more data frames arrive after I get this.

Example Response Frame

END OF FILE