Add Unix Domain Socket (uds) transport provider #439
+1,544
−2
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 <scottslewis@gmail.com>
UDSMcpSyncServerTest). Also made simplifying changes to *socketchannel classes
'EverythingServer' to allow Java mcp server to provide support for client tests...that currently use the JavaScript 'everything' server.
scottslewis
changed the title
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 <scottslewis@gmail.com>
UDSMcpSyncServerTest). Also made simplifying changes to *socketchannel classes
'EverythingServer' to allow Java mcp server to provide support for client tests...that currently use the JavaScript 'everything' server.
tests in UDSMcpAsync/Sync Server/Client Tests.
Now the only failing tests are those that are expecting specific
behavior of javascript everything server for tests.
io.modelcontextprotocol.client.AbstractMcpSyncClientTests.testCallTool()
fails because of this assertion
assertThat(result.isError()).isNull();
This is asserting that the isError is null...which it is in the
successful case for the javascript server. The java
TestEverythingServer, however the isError is false (not null). I
believe that false is correct (the java builder will not allow me to set
isError to null).
io.modelcontextprotocol.client.AbstractMcpAsyncClientTests.testCallToolWithInvalidTool()
line 247 has
e -> assertThat(e).isInstanceOf(McpError.class).hasMessage("Unknown
tool: nonexistent_tool"))
And the assertion fails because the java TestEverythingServer (included
in this pr) provides the message "Tool not found: nonexistent_tool"
io.modelcontextprotocol.client.AbstractMcpAsyncClientTests.testCallTool()
fails on line 232 with the same assertion error that
io.modelcontextprotocol.client.AbstractMcpSyncClientTests.testCallTool()
expecting isError to be null rather than false error.
Signed-off-by: Scott Lewis <scottslewis@gmail.com>
tests in UDSMcpAsync/Sync Server/Client Tests.
Now the only failing tests are those that are expecting specific
behavior of javascript everything server for tests.
io.modelcontextprotocol.client.AbstractMcpSyncClientTests.testCallTool()
fails because of this assertion
assertThat(result.isError()).isNull();
This is asserting that the isError is null...which it is in the
successful case for the javascript server. The java
TestEverythingServer, however the isError is false (not null). I
believe that false is correct (the java builder will not allow me to set
isError to null).
io.modelcontextprotocol.client.AbstractMcpAsyncClientTests.testCallToolWithInvalidTool()
line 247 has
e -> assertThat(e).isInstanceOf(McpError.class).hasMessage("Unknown
tool: nonexistent_tool"))
And the assertion fails because the java TestEverythingServer (included
in this pr) provides the message "Tool not found: nonexistent_tool"
io.modelcontextprotocol.client.AbstractMcpAsyncClientTests.testCallTool()
fails on line 232 with the same assertion error that
io.modelcontextprotocol.client.AbstractMcpSyncClientTests.testCallTool()
expecting isError to be null rather than false error.
Signed-off-by: Scott Lewis <scottslewis@gmail.com>
Signed-off-by: Scott Lewis <scottslewis@gmail.com>
UdsMcpClientTransport interfaces.
scottslewis
changed the title
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.