vllm p2p never connected zmq_exhaustion

Summary

When the OffloadingConnector uses TieringOffloadingSpec with a P2P secondary tier, an API client can submit many unique non-listening peer addresses through kv_transfer_params.prefill. vLLM keeps every never-established P2P session and its ZeroMQ sockets after the request finishes. On vLLM 0.26.0, 340 such peers filled the default ZeroMQ context socket quota; creating the next peer raised an uncaught ZMQError, terminated EngineCore, and shut down the API server. The path was reproduced with a normal API key and no access to the internal P2P listener.

Details

Root cause

In vLLM 0.26.0, P2PSecondaryTierManager.on_new_request() reads the following request-controlled fields:

{
  "kv_transfer_params": {
    "prefill": {
      "kv_request_id": "id",
      "remote_host": "127.0.0.1",
      "remote_port": 49101
    }
  }
}

on_new_request() calls _get_or_create_session(peer_id). This calls ZmqTransport.connect(), creates a P2PSession, and stores it in _sessions before the asynchronous ZeroMQ connection has been established.

ZmqTransport._open_connection() creates a DEALER, enables a libzmq monitor, creates a PAIR socket for that monitor, calls dealer.connect(), and immediately stores the resulting ZmqConnection in _connections. Returning from dealer.connect() does not prove that the peer is reachable.

The monitor subscribes only to zmq.EVENT_DISCONNECTED. A peer that never accepts the initial connection produced EVENT_CONNECT_DELAYED, EVENT_CONNECT_RETRIED, and EVENT_CLOSED, but no EVENT_DISCONNECTED during a 60-second observation. The production monitor therefore never calls , and remains true.