Not directly related to the article, but there is an experimental effort to develop a userland TCP stack in .NET right now.
It's interesting to see how this looks in a higher level language.
Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
11–20 of 50 posts
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#12Does anyone know why you would use an unsigned char array to store the MAC address instead of uint8_t? Char is one byte but a but a byte is not guaranteed to be 8 bits yet MAC is defined as 48 bits
Unless you are adding TCP to your CDC6600 or PDP-8, bytes are 8 bits. Any suggestion to the contrary in standards is fantasy. That said, since the next field is a uint16_t, you may as well stay in Rome and call them uint8_t. short really is variable on some live architectures. (Ok, or some DSPs only address words larger than 8 bits, but there's no reason for your compiler not to pick up the slack.) Also, TIL that __a…
I have another TIL for you... maybe you're a desktop/server developer... there are many embedded processor platforms where a byte is not 8 bits.
TI's C2000 microcontrollers - a byte is 16 bits. Other TI DSPs also have 16 bit bytes.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#13Earlier quoted context omitted.
Unless you are adding TCP to your CDC6600 or PDP-8, bytes are 8 bits. Any suggestion to the contrary in standards is fantasy. That said, since the next field is a uint16_t, you may as well stay in Rome and call them uint8_t. short really is variable on some live architectures. (Ok, or some DSPs only address words larger than 8 bits, but there's no reason for your compiler not to pick up the slack.) Also, TIL that __a…
I have another TIL for you... maybe you're a desktop/server developer... there are many embedded processor platforms where a byte is not 8 bits. TI's C2000 microcontrollers - a byte is 16 bits. Other TI DSPs also have 16 bit bytes.
Did you mean char?
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#14I use SLiRP over SSH as a poor man's VPN. It's ancient. The bulk of the code is a userspace TCP stack that performs NAT. I can use any SSH host as full VPN with only basic user privileges. I spent quite a bit of time poking around the code to try to improve performance. Increasing the receive window was sufficient to achieve >1Mb/s over a high latency link, but I can't go much higher without <100ms latency. It turns…
SLiRP, that's something which was used back in early 90's. With Trumpet Winsock and the one and only NCSA Mosaic browser.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#15Not directly related to the article, but there is an experimental effort to develop a userland TCP stack in .NET right now. It's interesting to see how this looks in a higher level language. https://github.com/ProjectMagma/Magma
Are there any blog posts about this? It looks like "Magma" is also something to do with Minecraft so it's really hard to find info about it.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#16Does anyone know why you would use an unsigned char array to store the MAC address instead of uint8_t? Char is one byte but a but a byte is not guaranteed to be 8 bits yet MAC is defined as 48 bits
Since the fixed width integer types are optional, and if available must be 8, 16, 32 and 64 bits (and two's compl) I don't think CHAR_BITS > 8 is allowed if stdint.h types are supported since sizeof(uint8_t) must be 1.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#17Does anyone know why you would use an unsigned char array to store the MAC address instead of uint8_t? Char is one byte but a but a byte is not guaranteed to be 8 bits yet MAC is defined as 48 bits
Unless you are adding TCP to your CDC6600 or PDP-8, bytes are 8 bits. Any suggestion to the contrary in standards is fantasy. That said, since the next field is a uint16_t, you may as well stay in Rome and call them uint8_t. short really is variable on some live architectures. (Ok, or some DSPs only address words larger than 8 bits, but there's no reason for your compiler not to pick up the slack.) Also, TIL that __a…
I don't see any reason in modern C to use int/short/long over explicit int32_t/int8_t/int64_t other than they're shorter to type.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#18Earlier quoted context omitted.
Unless you are adding TCP to your CDC6600 or PDP-8, bytes are 8 bits. Any suggestion to the contrary in standards is fantasy. That said, since the next field is a uint16_t, you may as well stay in Rome and call them uint8_t. short really is variable on some live architectures. (Ok, or some DSPs only address words larger than 8 bits, but there's no reason for your compiler not to pick up the slack.) Also, TIL that __a…
I don't see any reason in modern C to use int/short/long over explicit int32_t/int8_t/int64_t other than they're shorter to type.
I tend to use int for loops (where I know there will always be less than 2^16 iterations!), return codes etc. purely because it allows the compiler to pick a fast word size everywhere (e.g. if somebody compiles your code for AVR, and your loops are all int32_t, your API returns int32_t, they're gonna have a worse time). Otherwise, I fully agree.
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#19Earlier quoted context omitted.
I have another TIL for you... maybe you're a desktop/server developer... there are many embedded processor platforms where a byte is not 8 bits. TI's C2000 microcontrollers - a byte is 16 bits. Other TI DSPs also have 16 bit bytes.
Did you mean char?
[deleted]
Re: Let's code a TCP/IP stack, 1: Ethernet & ARP (2016)
#20Earlier quoted context omitted.
I don't see any reason in modern C to use int/short/long over explicit int32_t/int8_t/int64_t other than they're shorter to type.
I tend to use int for loops (where I know there will always be less than 2^16 iterations!), return codes etc. purely because it allows the compiler to pick a fast word size everywhere (e.g. if somebody compiles your code for AVR, and your loops are all int32_t, your API returns int32_t, they're gonna have a worse time). Otherwise, I fully agree.
Maybe you could use int_fast16_t? (That means, pick the fastest signed integer type which is at least 16 bits.)
Of course, "int" is less typing than "int_fast16_t". But, int_fast16_t possibly makes it more obvious why you've chosen the type you did (i.e. you only need 16-bits, but aren't relying on any overflow so a bigger type can freely be substituted if that gives better performance.)