3 ms·
> It is kinda fun to work directly at IP level and not use TCP or UDP at all. Possibly dumb question: if you're not using ports (because you're not using TCP a
by bscphil 5y ago
> It is kinda fun to work directly at IP level and not use TCP or UDP at all.
Possibly dumb question: if you're not using ports (because you're not using TCP at all), what does routing look like, in terms of this article? How does the kernel decide which traffic goes to application A and which traffic goes to application B? Or is all traffic directly visible to each application, if they aren't bound to a port? Can you bind to a specific IP, or just to an interface?
- YarickR2 5y agoThere are many more questions besides you've ready asked; basically, who or what is providing TCP-like transmission reliability and synchronisity, who's doing ICMP , who's doing fragmenting, and why does one need to reimplement better part of the stack
- simiones 5y agoThe normal way to "work directly at IP level" (or even below) is to use a RAW socket. The kernel will deliver all traffic matching the IP (or other things - raw sockets can essentially own the whole NIC) to your socket, and from there it's all up to you. The kernel will only look at the IP headers, the rest of the packet (TCP/UDP headers specifying ports, for example, if any) will be delivered to the raw socket. Not sure of the implementation details, but in principle the same logic about specificity of socket binding could be done by the kernel when deciding which socket to actually send the data to. Any other logic (CRC validation, packet ordering, confirming packets have been received, MSS etc.) are all disabled, you just get the raw packet as it was received on the wire, based on the IP headers (an the same happens when you send a packet on a raw socket).