Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StandardWebSocketClient providing inaccurate LocalAddress #22395

Closed
ahasbini opened this issue Feb 10, 2019 · 2 comments
Closed

StandardWebSocketClient providing inaccurate LocalAddress #22395

ahasbini opened this issue Feb 10, 2019 · 2 comments
Labels
status: invalid An issue that we don't feel is valid

Comments

@ahasbini
Copy link

Hello, I'm trying to develop a Spring based server that connects to another WebSocket Server using the classes StandardWebSocketClient and WebSocketConnectionManager.

Sample code below:

String webSocketServerUrl = "ws://someserver:9999/somepath";
WebSocketConnectionManager connectionManager = new WebSocketConnectionManager(
                new StandardWebSocketClient(), MyWebSocketHandler.this, webSocketServerUrl);
connectionManager.start();

Where MyWebSocketHandler has the method afterConnectionEstablished overridden as such:

@Override
public void afterConnectionEstablished(WebSocketSession session) throws Exception {
    logger.info("afterConnectionEstablished: outgoing session started {}",
            session.getLocalAddress());

The output of the log is as such:

afterConnectionEstablished: outgoing session started AHASBINI-PC/192.168.99.1:9999

When in fact I check my connections on my PC using tools and commands such as netstat -abn or netstat -apn and find out that the local connection is not from port 9999 but from a different port completely. I've traced the creation of the session to below lines found in StandardWebSocketClient.

@Override
protected ListenableFuture<WebSocketSession> doHandshakeInternal(WebSocketHandler webSocketHandler,
HttpHeaders headers, final URI uri, List<String> protocols,
List<WebSocketExtension> extensions, Map<String, Object> attributes) {
int port = getPort(uri);
InetSocketAddress localAddress = new InetSocketAddress(getLocalHost(), port);
InetSocketAddress remoteAddress = new InetSocketAddress(uri.getHost(), port);
final StandardWebSocketSession session = new StandardWebSocketSession(headers,
attributes, localAddress, remoteAddress);

Apparently it's setting the remote port and local port to the same value of the WebSocket Server URI.

However on the WebSocket Server which is receiving the connection via the apache Tomcat container and is also a Spring based implementation, the value of the remote and local ports are correct and not equal to each other within the WebSocketSession.

Thanks :)

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Feb 10, 2019
@rstoyanchev
Copy link
Contributor

Thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug.

@rstoyanchev rstoyanchev added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Feb 11, 2019
@ahasbini
Copy link
Author

ahasbini commented Feb 11, 2019

Hi @rstoyanchev and thanks for the reply. I'd like to state that a simple test would prove it, regardless of which server container used. The test only includes opening a websocket connection with any websocket server and validate the details of the connection from the application perspective and a OS perspective to see the inconsistency. I believe that this is doable by anyone with little understanding of networking.

Here's a sample test code:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.client.WebSocketConnectionManager;
import org.springframework.web.socket.client.standard.StandardWebSocketClient;
import org.springframework.web.socket.handler.TextWebSocketHandler;

import java.io.IOException;

public class SampleTest extends TextWebSocketHandler {

    private static final Logger logger = LoggerFactory.getLogger(SampleTest.class);


    public static void main(String[] args) throws IOException, InterruptedException {
        SampleTest test = new SampleTest();
        test.testWebSocket();
    }

    private void testWebSocket() throws InterruptedException, IOException {
        WebSocketConnectionManager connectionManager = new WebSocketConnectionManager(
                new StandardWebSocketClient(), this,
                "ws://127.0.0.1:9999/test");
        connectionManager.start();

        Thread.sleep(10000);

        connectionManager.stop();
    }

    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        logger.info("afterConnectionEstablished: initiated connection {} - {}",
                session.getLocalAddress(), session.getRemoteAddress());
    }
}
<dependency>
    <groupId>org.glassfish.tyrus.bundles</groupId>
    <artifactId>tyrus-standalone-client</artifactId>
    <version>1.9</version>
</dependency>

The application log outputted the below:

21:09:00.746 [Grizzly(1)] INFO  com.emcrey.rambus.integration.SampleTest -  - afterConnectionEstablished: initiated connection AHASBINI-PC/192.168.99.1:9999 - /127.0.0.1:9999

But from the command prompt the below is observed:

C:\WINDOWS\system32>NETSTAT.EXE -abn | find "9999"
  TCP    0.0.0.0:9999           0.0.0.0:0              LISTENING
  TCP    127.0.0.1:9999         127.0.0.1:32384        ESTABLISHED
  TCP    127.0.0.1:32384        127.0.0.1:9999         ESTABLISHED
  TCP    [::]:9999              [::]:0                 LISTENING

Note that my websocket server is hosted on the same machine. Notice how the second port 32384 is not mentioned anywhere in the app log, and there's no connection from port 9999 to itself, it also can't be possible with client and server existing on same machine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: invalid An issue that we don't feel is valid
Projects
None yet
Development

No branches or pull requests

3 participants