Network path

HarvTTP does not talk through a host socket in the CPU-real path. It drives the HarvOS HNET MMIO network device. In the Verilator test path, Ethernet frames are bridged to the host-side test network through the configured packet bridge.

HNET flow

HarvTTP enables the network device with HARVOS_NET_CTRL_ENABLE and configures interrupts.
The service writes its MAC address to MAC_LO and MAC_HI.
On receive, RX_VALID causes HarvTTP to start an RX_START transfer.
HNET places the frame in the DMA window and reports FRAME_LEN.
On transmit, HarvTTP copies a frame into the DMA window and starts TX_START.
The TX worker drains the bounded queue whenever HNET reports transmit capacity.

Protocol stack

Layer	Implemented	Limit
Ethernet II	MAC addresses plus EtherTypes `0x0800` and `0x0806`.	No VLAN and no multicast-management logic.
ARP	Replies to requests for the DHCP-assigned server IP.	No general ARP cache policy for arbitrary outbound clients.
IPv4	Minimal header, checksum, TTL 64 and Don't Fragment.	No fragmentation or reassembly.
UDP/DHCP	Discover, Offer, Request and Ack with XID checks.	No complete DHCP lease-renewal state machine.
TCP	SYN/SYN-ACK, sequence tracking, HTTP response, FIN/RST handling and peer aging.	No complete retransmission, congestion control or window scaling.
HTTP	HTTP/1.0, GET, selected POST handling, Content-Type, Content-Length and Connection close.	No TLS and no keep-alive connection pool.

DHCP state machine

state DISCOVER:
  send DHCPDISCOVER
  wait for OFFER with matching XID

state REQUEST:
  send DHCPREQUEST for offered IP
  wait for ACK with matching XID

state ACK:
  net.bound = true
  HTTP traffic on port 80 is accepted

After the server is bound, HarvTTP reports its address through the audit/IPC path. In the current local test setup the service has often appeared as 192.168.8.231, but the real address is always assigned by the active DHCP test network.

Transmit behavior

The current implementation uses hybrid transmit behavior. If HNET is ready and the queue is empty, HarvTTP sends immediately. Otherwise the frame is copied into a 64-slot queue and the TX worker drains it in batches. This keeps low-load latency small while preventing short response bursts from being discarded as soon as PHP or SQL paths start emitting more data.

SQL loopback

PHP code reaches HarvSQL through a loopback-style client path inside HarvTTP. The HTTP service owns the HNET device today, so database requests are multiplexed through HarvTTP's SQL client state rather than by letting HarvTTP and HarvSQL drive the same NIC independently. A production system should move this arbitration into a supervisor or netd-style service.

Browser access

The browser must reach the DHCP address of the HarvOS server. 127.0.0.1 is only correct when an explicit proxy or port forward has been configured. For the CPU-real path, use the address assigned inside the HarvOS test network, for example http://192.168.8.231/.