Wrong TcpStack.open definition, or comment?

[MathiasKoch]

Wrong TcpStack.open definition, or comment?

[MathiasKoch]

After starting to implement it, i guess it makes a bit sense if its the comment being off.
I guess open, would actually just allocate the socket handle and set the mode flag? eq. of eg. AT+USOCR.

[MathiasKoch]

How would you with this interface open and connect to at TCP remote?

As far as i see it, it is missing a reference between open and connect?
To me it seems like connect is missing an argument referring to the TcpSocket returned by open()?

Also i am not sure how one would implement this trait on any devices, when open and connect does not hold a reference to self, possibly even mutably. I don't think you would be able to open or connect to a socket over any bus (Serial, SPI, I2C) without a mutable self reference? And following that thought i think all the functions should have that &mut self, in order to communicate with the hardware peripherals it owns?

[thejpster]

My understanding of Berkley sockets is that open() creates the socket (so you have a file descriptor) but it is in the "unconnected" state until you call connect(fd, sock_addr, sock_addr_len). I've now fixed the comment for TcpStack::open.

You are right, the trait functions need a self or mut self reference. I think self is the right place to start, otherwise you can't share the stack between multiple distinct things (like an HTTP client and a Telnet client). The stack implementation will need to have some internal mutex to hold its state.

[thejpster]

Thanks for the issue by the way. I hope this simple crate is at least thought-provoking, and maybe even somehow useful.