[Jeff Foster <jfoste@xxxxxxxxxxxx>]

Richard's letter provoked some ideas about the ethereal TCP and higher
dissectors.

I suggest that we change the tcp and tcp sub-dissectors from the current
'data
push' where the tcp dissector passes the packet data to the sub-dissector to
a
'data pull' system where the sub-dissector requests data from the tcp
dissector.

1) The tcp dissector will handle all packet ordering and retransmission
problems.

2) The tcp dissector will inform the sub-dissector when a new connection is
created and it will provide a SYN flag to indicate that this is really the
start
of the stream.

2) The tcp will call the sub-dissector each time data is received on the
stream.

3) The sub-dissector is required to tell the tcp dissector which function to

call next for both the send and receive data stream.  In essence creating a
state
machine for the dissector with the tcp dissector holding the state info.

4) The sub-dissector will request data from the tcp dissector.

5) The sub-dissector will inform the tcp dissector as it consumes data so
the
data is removed from the tcp data buffers.


The execution flow when a tcp packet is received -

tcp dissector does data sequencing and retransmission checks.
tcp dissector call sub-dissector send/recv function
sub-dissector requests data from tcp dissector 
sub-dissector processes data if enough available and tell tcp dissector to
	remove processed data from head of data stream.
sub-dissector changes send/recv function if required.


Data structs -

Tcp conversation struct {

	recv_sequence_num;	/* current recv stream sequence number */
	send_sequence_num;	/* current send stream sequence number */

	recv_data_start;		/* pointer to first per packet data
for recv data */
	send_data_start;		/* pointer to first per packet data
for send data */

	recv_data_end;		/* pointer to last per packet data for recv
data */
	send_data_end;		/* pointer to last per packet data for send
data */

	send_callback;			/* stream send callback */
	recv_callback;			/* stream recv callback */
}

Tcp per packet struct {

	sequence_num;		/* sequence number for this packet */
	prev_packet_ptr;		/* prev packet in the stream */
	next_packet_ptr;		/* next packet in the stream */
	data_len;			/* length of data */
	data_ptr;			/* pointer to data storage */
	display_row; 		/* packet display row */
}

NOTE:  The prev/next_packet_ptr's follow the data stream not the packet
	received order.


Functions -

/* Each sub-dissect will register one of these routines instead of the */
/* current sub-dissector registration we have today.  The sub-dissector */
/* would at the minimum have to call the tcp_send_dissector and
*/
/* tcp_recv_dissector */

protocol_XXX_stream_start( 		/* called at the beginning of each
stream creation */
	boolean syn_flag		/* syn flag set, normal stream start
*/
);


/********** These functions will are in the tcp code **********/

/* sub-dissector uses this to tell tcp dissector which function to call next
*/
/* for send data */

tcp_send_dissector(
	tcp_steam_ptr, 
	dissect_ptr;		/* dissector to call when send data
available */
);

/* sub-dissector uses this to tell tcp dissector which function to call next
*/
/* for recv data */

tcp_recv_dissector(	
	tcp_steam_ptr, 
	dissect_ptr;		/* dissector to call when recv data
available */
);


/* Sub-dissect will call these function to get more data from the tcp stream
*/

tcp_get_send_data(  		/* request send data, return data pointer */
					/* return 0 if not enough data */
	tcp_steam_ptr,		/* tcp conversation pointer */
	data_len		/* how much data is wanted, a value of zero
indicates */
				/* give all the data you have. */
);

tcp_get_recv_data( 		/* same as tcp_get_send_data */
	tcp_steam_ptr,
	data_len
);

/* Sub-dissector uses this to tell tcp dissector it has processed this */
/* much send data. The tcp dissector will release the per packet stream */
/* data storage */

tcp_send_data_done(	
	tcp_steam_ptr, 
	data_len		/* how much data has been used */
);

tcp_recv_data_done( tcp_steam_ptr, data_len);	/* same as
tcp_send_data_done */



Questions -

How to handle holes in the data stream? 
	Is a 'start of data holes' pointer needed?
How to handle urgent pointer, special urgent callback ?
Need to better clarify retransmission, should the original packet be
indicated?
How to handle display fields that are spread over multiple packets?
	Is the field displayed in the first packet or last packet?
	How does the user know that the data extends beyond the packet?
How does this all fit into the ethereal proto_tree code?
How will this work with tethereal?
How does this work with the current conversation code?  Can the tcp
dissector 
and a sub-dissector both create a conversation on the same stream?

Jeff Foster
jfoste@xxxxxxxxxxxx