feat: Add socket transport as an alternative to stdio transport

[qhhonx]

This PR introduces socket transport as an alternative to the existing stdio transport, offering similar process management capabilities but with enhanced flexibility through TCP socket communication.

Relationship with stdio Transport

The socket transport implementation follows similar patterns to the existing stdio transport:

Shared Patterns:

• Process management and lifecycle handling
• Stream-based communication model
• Resource cleanup mechanisms
• Error handling approaches
• FastMCP integration model

Key Differences:

1. Communication Channel:

   • stdio: Uses stdin/stdout pipes
   • socket: Uses bidirectional TCP sockets

2. Connection Management:

   • stdio: Immediate pipe connection
   • socket: Supports connection retry and timeout

3. Deployment Flexibility:

   • stdio: Limited to local process communication
   • socket: Supports both local and network communication

4. Configuration Options:

   • stdio: Fixed to system pipes
   • socket: Configurable host/port settings

5. Error Handling:

   • stdio: Basic pipe error handling
   • socket: Advanced connection and network error handling

Implementation Details

The implementation maintains consistency with stdio transport while adding socket-specific features:

1. Process Management:

# stdio transport
async with stdio_client(server_params) as (read_stream, write_stream):
    # Use streams...

# socket transport (similar pattern)
async with socket_client(server_params) as (read_stream, write_stream):
    # Use streams...

2. Server Integration:

# stdio server
server.run(transport='stdio')

# socket server (consistent API)
server.run(transport='socket')

3. Configuration:

# stdio parameters
StdioServerParameters(
    command='python',
    args=['-m', 'server'],
)

# socket parameters (extended but similar)
SocketServerParameters(
    command='python',
    args=['-m', 'server'],
    host='127.0.0.1',  # Additional socket-specific options
    port=8000,
)

Enhanced Capabilities

The socket transport adds several capabilities not possible with stdio:

1. Network Communication:

   • Support for remote process communication
   • Configurable network parameters
   • Better support for distributed systems

2. Connection Management:

   • Retry mechanisms for reliability
   • Timeout handling for better error recovery
   • More robust error handling

3. Deployment Options:

   • Flexible host/port configuration
   • Support for various network topologies
   • Better scalability options

Migration and Compatibility

The socket transport is designed to be a drop-in alternative to stdio transport:

# Existing stdio usage
server = FastMCP(name='Server')
server.run(transport='stdio')

# New socket transport usage
server = FastMCP(
    name='Server',
    socket_host='127.0.0.1',
    socket_port=8000,
)
server.run(transport='socket')

Testing Strategy

Tests are designed to verify both shared behavior with stdio and socket-specific features:

1. Shared Behavior Tests:

   • Process lifecycle management
   • Stream communication patterns
   • Resource cleanup
   • Basic error handling

2. Socket-Specific Tests:

   • Network connection handling
   • Timeout and retry mechanisms
   • Host/port configuration
   • Network error scenarios

Future Considerations

1. Potential Enhancements:

   • TLS/SSL support for secure communication
   • Unix domain socket support
   • Performance optimizations
   • Advanced network configurations

2. Migration Tools:

   • Consider adding utilities to help migrate from stdio to socket transport
   • Add documentation for choosing between transports

[Kludex]

I don't think we want to keep including transports into this package that are not in the MCP specification.

I think the best approach for now would be to create a mcp-socket package (or something similar).

---

That said, I think this transport should support fds and uds as well.