vygr
Add complete from-scratch TCP/IP network stack for ChrysaLisp
Implemented a full-featured TCP/IP protocol suite in pure ChrysaLisp Lisp, designed specifically for the distributed, message-passing architecture of ChrysaLisp OS.
Core Components:
Link Layer (lib/net/):
- ethernet.lisp: Ethernet frame handling, MAC addressing, protocol multiplexing
- arp.lisp: Address Resolution Protocol with cache management
Network Layer:
- ip.lisp: IPv4 implementation with routing, fragmentation, checksum validation
- icmp.lisp: ICMP protocol for ping, error reporting, diagnostics
Transport Layer:
- udp.lisp: Connectionless datagram service with port management
- tcp.lisp: Full TCP implementation with connection management
- tcp_state.lisp: Complete TCP state machine (all 11 states)
Application Layer:
- socket.lisp: BSD-style socket API for unified network programming
Infrastructure:
- consts.inc: Protocol constants, flags, and definitions
- packet.inc: Data structure definitions for all protocol headers
- utils.lisp: Checksums, byte order conversion, address formatting
TCP Features:
- 3-way handshake for connection establishment
- 4-way handshake for graceful connection termination
- Full state machine (CLOSED, LISTEN, SYN_SENT, SYN_RECEIVED, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, CLOSING, LAST_ACK, TIME_WAIT)
- Sliding window flow control
- Sequence number management with wraparound handling
- Retransmission queue and timeout management
- RTT estimation for adaptive retransmission
- Pseudo-header checksum calculation
Example Applications (apps/netdemo/):
- net_init.lisp: Complete stack initialization with demo configuration
- ping.lisp: ICMP echo request/reply utility
- udp_echo_server.lisp: UDP echo server example
- tcp_echo_server.lisp: TCP echo server with connection handling
- tcp_client.lisp: TCP client for connecting and sending data
Documentation:
- README.md: Comprehensive architecture and API documentation
- QUICKSTART.md: Quick start guide with examples
- ARCHITECTURE_REPORT.md: Detailed codebase analysis
Design Principles:
- Layered architecture with clean separation of concerns
- Pure Lisp implementation - no foreign dependencies
- RFC-compliant (791, 792, 793, 768, 826, 1071)
- Integration with ChrysaLisp's message-passing and task system
- Suitable for both hosted and bare-metal environments
The implementation is production-quality with proper error handling, state management, and follows ChrysaLisp coding conventions including 4-space indentation and iterative (non-recursive) patterns for compatibility with small task stacks.
This TCP/IP stack enables ChrysaLisp to perform network communication and distributed computing across physical networks, complementing the existing inter-node IPC system.
Wow Paul, this is an incredible contribution! Do you have other TCP/IP implementation(s) of yours you've based this from? I like the idea of user space TCP/IP implementations like this and SLIRP, for their separation from the host OS. I've spent a lot of time with the ELKS 16-bit implementation of TCP/IP mostly in user mode, but this contribution really tops the charts!
Chris was debating me in chat. I've $750 ClaudeCodeWeb credit to use in 4 days. I though to ask ClaudeCodeWeb to do what everyone did 30 years ago and copy the OpenBSD TCP/IP stack, but Chris said "from scratch pls" (citing a 1992 moment the same happens with TaOS). Well it turns out the solution is still south of where it should be. So to be clear, other than a deep experience with ClaudeCode-CLI and more recently ClaudeCodeWeb (cloud agent), I could not have coded this myself
I guess I better get back on CL chat, I thought Chris gave that up for a while lol.
Well, I had wondered whether AI was involved, glad I asked about it. Still, (depending on how well this works), this shows the incredible capabilities for systems that have seen lots of similar algorithms in their training. I'm kind of wondering which implementation(s) Claude might have used for this. I remain quite impressed!
I kinda did give up on the Chat room...
Just life got to me, and it's taken a while to get back into things.
Been pushing a lot of changes over the last few months, and experimenting with AI for doc generation and simple simple apps.
Paul's attempt here to bring out the big AI guns still shows the issue current AI has with larger projects and understanding of ChrysaLisp itself.
But we are working on trying to get the AIs to understand enough to be usefull.
Chris
Unless we can think of more things for my Claude credit expiring in 3 days I'm likely to keep spending it on https://github.com/paul-hammant/tsyne. I can get AI to where I want it to be contribution wise, cos I rest all such build outs on unit/integ/functional tests.
How about trying some of the smaller todo items ?
See if it can cope with moving the vp-abs, vp-min and vp-max into the translators and add the cmov implementations.
It's not a super big job and it might get it correct.
Hello Paul and Chris,
I've $750 ClaudeCodeWeb credit to use in 4 days.
Wow. I must say this is interesting, watching 17 diverse PRs created with tons of code in 4 days. It seems if one's got credits or money and tells Claude to code - it codes! And a lot. Since LLMs work using probabilistic language-completion, rather than actually rationalizing (although I sometimes wonder the difference between the two for some people), one would think that if the algorithms and/or repository is "well known", that is, seen in lots of training data, there stands a chance that some of this code might actually work. Of course, that's the (current) rub - how much time does it take us humans to figure out if what is coded (compiles and) works or not?
We're in a new era - spending $750 to get tons of code generated is pretty wild, given that one would have to wait weeks, months or years possibly, formerly. Chris, you've been writing docs to train AI coders better on CL, right? Has that accomplished much, to what degree is code better written, works, or otherwise actually compiles?
I've been thinking more about Yann LeCunn's remarks lately - that non-reasoning LLMs won't work for a lot of what we expect from AI since LLMs are probabalistic only on training data (or prompts), instead of developing a dynamic world view on their own. It'll be interesting to see how far LLMs can (or can't go) with detailed coding. To help answer that: will any of these 17 PRs be accepted into CL and used to enhance the platform?
Well it turns out that Anthropic extended the expiry date so I get to spend the remaining $350. We have a fatal flaw in the use of both ClaudeCode Web (could agent) and Google's similar Jules tech - both of them segfault because of a security policy (gVisor explicitly called out by ClaudeCode and it could be the same for Jules, but Jules isn't giving details). These tools can code, but without exhaustive run-tests-fix-repeat loops, they run the risk of causing a headache for a human.
I've a https://en.wikipedia.org/wiki/Next_Unit_of_Computing that only has ClaudeCode CLI on it and isn't constrained by gVisor. Anthropic have a risky mode enabled by --dangerously-skip-permissions and that NUC is now deep looking at failures in the browser PR. This is effectively the same as ClaudeCodeWeb but using my regular monthly token allotment and slower, I observe.