[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] towards a common Mirage 'FLOW' signature



On 16 Jun 2014, at 10:23, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> On 16 Jun 2014, at 09:55, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
> wrote:
> 
>> i generally like the idea of doing something other than an ad hoc collection 
>> of callbacks.
>> 
>> how would the scheme above handle recursive protocols (IP-in-IP etc)?
> 
> You would narrow the buffer by classifying it, generating a sub-view, and 
> making that a FLOW again.  I don't think that this interface should concern 
> itself with doing a deep packet inspection, unless I'm missing something?

i guess what i mean is i'm (still, after years) not clear on the relationship 
between a FLOW and the demultiplexing of protocols. or does every layer of the 
stack effectively allow a FLOW to be read from so that at the lowest layer 
every read might return a new ethernet frame, at a layer above that you might 
get an IP packet per read, at the layer above that you might get a chunk of 
data off a TCP connection bearing no relationship to the underlying TCP 
segmentation? or you'd get a TCP segment every time?

>> (probably irrelevant but fwiw: i tried doing something a little like this 
>> with the pcap code -- so there was a set of default "demux" functions but 
>> you could override them all to construct your own protocol demux dag.)
> 
> Got a pointer?  Should make sure the two are compatible.

it's still half assed but fwiw: https://github.com/mor1/ocaml-pcap


-- 
Cheers,

R.




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.