Initial proposal to for feature request https://github.com/modelcontextprotocol/java-sdk/issues/415 #439
+1,188
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
modelcontextprotocol#415 i.mcp.client/server.transport packages contains new transport providers classes : UDSClient/ServerTransportProvider. The name UDS refers to UnixDomainSocket as that's the SocketChannel type being used. These transport providers use the new classses in util: UDSClientNonBlockingSocketChannel and UDSServerNonBlockingSocketChannel. These further depend upon super classes ClientNonBlockingSocketChannel and ServerNonBlockingSocketChannel which both depend upon superclass NonBlockSocketChannel, which has most of the actual implementation of the single-threaded/Selector based non-blocking read and write. This subclass/superclass structure means that Inet4 and Inet6 client/server SocketChannel classes are also present. These will work just the same as the UDSClient/ServerSocketChannel classses but rather will use Inet4 and Inet6 connections rather than UnixDomainSockets. It will be very easy to create server/client transport providers that use inet4 or inet6 tcp stacks for localhost or non localhost connections. But for the moment, I've only created UDSServer/ClientTransportProviders for testing and review. Signed-off-by: Scott Lewis <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial pr for feature request: #415
i.mcp.client/server.transport packages contains new transport providers classes : UDSClient/ServerTransportProvider. The name UDS refers to UnixDomainSocket as that's the SocketChannel type being used.
These transport providers use the new classses in util: UDSClientNonBlockingSocketChannel and UDSServerNonBlockingSocketChannel.
These further depend upon super classes ClientNonBlockingSocketChannel and ServerNonBlockingSocketChannel which both depend upon superclass NonBlockSocketChannel, which has most of the actual implementation of the single-threaded/Selector based non-blocking read and write.
This subclass/superclass structure means that Inet4 and Inet6 client/server SocketChannel classes are also present. These are very simple, and will work just the same as the UDSClient/ServerSocketChannel classses but will use Inet4 and Inet6 + port connections rather than UnixDomainSockets.
It will then be very easy to create server/client transport providers that use inet4 or inet6 tcp stacks for localhost or non localhost connections.
But for the moment, I've only created UDSServer/ClientTransportProviders for testing and review.
Motivation and Context
Especially for localhost only communication, it would be valuable to use transport providers that are not based upon stdin and stdout
How Has This Been Tested?
Yes, I have tested these transport providers with my own MCP server and client impls. Mostly in java, but also in Python.
Breaking Changes
Types of changes
Checklist
Additional context
I'm completely willing to help with restructuring server/client transport providers to allow the easy use of the *NonBlockingSocketChannel classes. I'm not hung up on these class names or package locations...if alternatives are better then I'm willing to refactor.