What's different about using sockets on a constrained embedded device versus a PC?

Several things, all rooted in scarce resources and no general-purpose OS. Sockets are a limited, RAM-costed resource: an embedded stack like lwIP is compiled with a fixed maximum number of sockets/PCBs and fixed buffer pools, so you can't open them freely, you must always close() to avoid leaking them, and you design to reuse a single persistent connection rather than open many. Concurrency is constrained: there's often no thread-per-connection model, so you use non-blocking sockets with select/poll or the stack's callback API to avoid stalling the main loop (a blocking call can hang the system and trip the watchdog). The API may differ: lwIP offers the familiar BSD socket API but also lighter "raw"/netconn APIs that avoid the copy and thread overhead, and you pick based on your RAM and architecture. Memory tuning is explicit, you size receive/send buffers, the number of TCP PCBs, and window sizes against available RAM, trading throughput for footprint. And surrounding services you take for granted on a PC (DNS resolution, a full TLS library, large MTUs) are limited or must be added deliberately. So embedded socket programming is the same conceptual API but with hard caps on connection count and buffers, an event-driven rather than blocking-thread model, and constant attention to RAM.