13:52 <andrea_> anyone here knows about tcp/ip stack codebase?

13:57 <hannes> andrea_: I looked into parts of it.

13:59 <hannes> andrea_: feel free to ask either in here what you want to know, or open an issue at the bug tracker at https://github.com/mirage/mirage-tcpip

14:03 <andrea_> Thanksmirage tcp ip

14:05 <andrea_> sorry for the wrng paste

14:06 <andrea_> I'm looking at the pcb.ml

14:07 <andrea_> There is a function 'input' that is the main inout function of tcp calls

14:07 <andrea_> I'm wondering when this function would be actually called?

14:11 <hannes> andrea_: this is correct, it is called by Flow.input, which in turn is called by the IP layer (in static_ipv4.ml there's another input, which receives the tcp input as callback), which is called by the ethif.ml

14:13 <andrea_> interesting

14:14 <hannes> andrea_: the glue for the stack is located in stack-direct/tcpip_stack_direct.ml in the functionlisten -- which is the one called by an application

14:16 <andrea_> great answer, I will look at it in detail later and come back to this room for further discussion

14:16 <andrea_> Thanks hannes

14:17 <hannes> andrea_: disclaimer: i'm not the author of that tcpip

14:17 <hannes> indeed, i've looked at it various times with things which were very unclear to me... and i'm slowly rewriting another tcp stack in ocaml ;)

14:18 <andrea_> I think I've seen your comments in the code

14:19 <andrea_> (* XXX: I've no clue why this is the way it is (10000 + Random ~bound:10000) -- hannes *)

14:19 <hannes> yes, that was me from adjusting the stack to a new random number interface.... but unfortunately nobody answered

14:20 <hannes> it seems to me that the original authors are busy with other things or consider it to be "finished" or "working"..

14:20 <andrea_> finished is a bit unfair I guess, they might be busy with docker stuff!?

17:03 <andrea_> hannes: I have a question about tcpip_stack_direct.ml if you are still there

18:01 <hannes> andrea_: i'm back

18:32 <andrea_> in tcpip_stack_direct.ml, function 'connect' calls 'Lwt.ignore_result (listen t)'. Since this call starts a listening thread in background, what happens if that thread exists unexpectedly? Caller will never find out

18:33 <andrea_> hannes: ^

19:52 <hannes> andrea_: that's true.

19:53 <hannes> andrea_: I think the idea is that "listen t" should never fail... we worked towards using explicit result (error) values in Mirage-3, and don't use the error monad of Lwt anymore (at least that's the idea, I'm not sure whether there are still cases where Lwt.fail is used)

20:20 <andrea_> do you know how it is handled in mirage-3?

20:34 <hannes> andrea_: as written in https://mirage.io/blog/announcing-mirage-30-release instead of having "read : t -> Cstruct.t Lwt.t", we now use "read : t -> (Cstruct.t, read_error) result Lwt.t" -- which means that the read_error is no longer embedded as Lwt.fail, but explicit (as Ok <data> or Error `Read_error in the code)