Semi E37.1

SEMI E37.1 and E37.2 define the two session modes HSMS (SEMI E37) actually runs in: HSMS-SS (Single Selected-Session), where one TCP connection carries exactly one SECS-II session between a host and a single piece of equipment, and HSMS-GS (General Session), where one TCP connection can multiplex several independent SECS-II sessions to different logical entities at once. E37 itself only establishes that SECS-II messages travel over TCP/IP; it doesn't say whether a connection represents one conversation or several, which is exactly the gap E37.1 and E37.2 close — and the choice between them determines how a host's connection-management code has to be written.

The practical reason this distinction matters is that most single-chamber equipment in the field uses HSMS-SS — simple, one connection per tool, which is why it's the mode most engineers mean when they say "HSMS" without qualification — while HSMS-GS exists specifically for configurations where one network endpoint needs to represent several logical sessions, such as a host gateway multiplexing communications to multiple subordinate entities behind a single TCP connection, or a cluster tool exposing several chamber-level sessions through one physical link. Getting this wrong in host software is a real integration failure mode: code written assuming HSMS-SS's one-session-per-connection model will misinterpret or drop messages from an HSMS-GS connection's additional sessions, because it has nowhere in its state machine to track a Session-ID beyond the single implicit one HSMS-SS doesn't require the host to manage explicitly.

E37.1 and E37.2 are the two concrete shapes the SECS/HSMS/GEM stack can take at the transport layer, and the choice between them is settled once at integration time — it isn't something a host renegotiates per message, which is why getting it right before writing connection-handling code matters more than almost any other HSMS detail.