Handshake Error about signalr-client-swift HOT 11 CLOSED

Are you able to reproduce this consistently? From your descriptions it feels that the client did not receive messages in the expected order (or somehow missed the first message). As per the protocol description the first message sent by the client should be handshake request. Upon receiving the handshake request the server should respond with handshake response which optionally can contain an error. A successful handshake response is an empty JSON object. What you are receiving is a ping message of JSON hub protocol. While this is a valid JSON it is not a valid response to the handshake request and is rejected by the client which closes the connection.
If you have a consistent (simplified) repro, can you post it somewhere (for instance as a github repo) so that I could try replicate on my side? I think, I would mostly need the server side since you posted the client side code.
Alternatively, if you installed the client from CocoaPods - can you try installing the version from the master branch of this repo and check if the issue persists?

from signalr-client-swift.

Sorry for long respond, i had a weekend)
Here is a short sample. I can not send our server code, because of it is not a open source product.
Native SignalR javascript lib works with it fine. I attach a short script that demonstrate that connection works and after channel subscribtioning the data comes from server
SignalRCoreTest.zip
js_signalrlib_test.zip

from signalr-client-swift.

Would you be able to come up with a minimal repro from the server side? Since the issue is happening when starting the connection I would think that it would also happen even if your hub did not have any hub methods. I am mostly interested in seeing:

• versions in the .csproj
• setting up the server (main/StartUp)
• did you override the OnConnectedAsync method in your hub? If so, does the issue still occur if this logic does not run?
• do you use authentication? If so, does the issue still occur if auth is disabled?
• how you are running your server (OS, if Windows - are you using IIS), Azure?

Can you also try the latest version of the client from the master branch (you can do it by changing your Podfile like this) and turn on logging at the Diagnostic level? The default PrintLogger will log to the console and hopefully will help troubleshoot.

from signalr-client-swift.

answers for your questions:

1. <PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.0.0-preview1-final" />

        public static ISignalRBuilder AddMyExJsonProtocol(this ISignalRBuilder builder,
                                                          IHostingEnvironment env,
                                                          Action<JsonHubProtocolOptions> configure = null)
        {
            return builder.AddJsonProtocol(o =>
            {
                o.PayloadSerializerSettings.ApplyMyJsonSettings(env.IsProduction());
                configure?.Invoke(o);
            });
        }

        app.UseSignalR(ConfigureSignalR);

        private static void ConfigureSignalR(HubRouteBuilder routes)
        {
            routes.MapHub<MarketInfoHub>("/info");
        }

3. No
4. No
5. kestrel behind azure load balancer and nginx reverse proxy.

And I use your latest version from master branch, it is a big difference beetween standart cocoapod. And it works anoter. Now new problem appears. In your code:

private static func parseAvailableTransports(negotiationResponseJSON: [String: Any?]) throws -> [TransportDescription] {
        guard let transports = negotiationResponseJSON["availableTransports"] as? [[String: Any?]] else {
            throw SignalRError.invalidNegotiationResponse(message: "availableTransports property not found or invalid")
        }

        return try transports.map { try parseTransport(transportJSON: $0) }
    }

problem with parsing, it trows here because of SignalR server returns {"connectionId":"f2594bbe-9c1a-48cc-ba48-aef1f71447a9","availableTransports":["WebSockets","ServerSentEvents","LongPolling"]} and lib parse it with an error. I can fix it, but i want to understand why this problem appears?

I can provide logs here:

2018-08-20T14:34:14.643Z info: Starting hub connection
2018-08-20T14:34:14.652Z info: Starting connection
2018-08-20T14:34:14.653Z debug: Attempting to chage state from: 'initial' to: 'connecting'
2018-08-20T14:34:14.655Z debug: Changing state to: 'connecting' succeeded
2018-08-20T14:34:18.908Z debug: Negotiate completed with OK status code
2018-08-20T14:34:18.908Z debug: Negotiate response: {"connectionId":"2ce14177-d9fe-4097-95c0-4d04bdbb5da0","availableTransports":["WebSockets","ServerSentEvents","LongPolling"]}
2018-08-20T14:34:20.615Z error: Parsing negotiate response failed: invalidNegotiationResponse("availableTransports property not found or invalid")

And here is a small code sample were you can test it (just change a team provisioning before run)
SignalRCoreTest.zip

from signalr-client-swift.

By code reading i see, that you need Json of "availableTransports" that contains TransportType("WebSockets","ServerSentEvents","LongPolling") and also TransportFormat("Text","Binary") can you explain why our server returns only TransportType and it crashes the lib?
We use original MS SignalR and do not change anything, this is strange, may be some lib initialize settings on server we need for your client lib?

from signalr-client-swift.

<PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.0.0-preview1-final" />

I believe this is the issue. The preview1 is a very old version of SignalR and there was a number of protocol changes introduced after preview1. Given that there were 3 stable versions of SignalR released none of the previews are supported. I assume that the js client works with your server because you use the matching version. Please update your server (and the js client) to the latest (or at least a stable version) and I think the Swift client will work (I am testing the client with the latest stable version of the server)

from signalr-client-swift.

Thanks for help, we found that Stable versions have an issue of unable to add custom messages to errors/exceptions. Our teammate disscuss it here aspnet/SignalR#2609

Can you check if version you use provide it or have the same error?

from signalr-client-swift.

My understanding is that the issue is on the server side. The client does not see the error message because the server does not send it. You could try using the nightly build to verify if your issue is fixed. As noted in the other bug the fix is planned to be released in the next minor update.
I am also not sure why a missing error message would block updating a pre-release version to a stable version. There have been tons of bug fixes and improvements post preview1 and relying on error message to do meaningful work seems wrong.

from signalr-client-swift.

In code samples in the issue above (
aspnet/SignalR#2609) server sent an error to client, and client do not get the message. Our server covered with tests and it works well now, we can merge to a newer version, but we need a server error messages sent to client.

I understand what you prefer, thanks a lot, we try to update a lib but at first try to use Embeddinator-4000(https://github.com/mono/Embeddinator-4000) for using C# lib of current version in Native swift/obj-c. Do you try to use it for SignalR?

from signalr-client-swift.

but we need a server error messages sent to client.

Can't you just show a generic error message on the client in case of an error until the version with the fix is shipped? I would think that, since this is an exception, it should not happen too often so I am not quite sure why you need to optimize for this case. Anyways, the client cannot do anything about this since the issue is on the server side.

I have not tried the Embeddinator - when I saw it the last time it was at a very experimental stage. I also am working on this client with different goals in mind. At any rate, even if Embeddinator worked it would not help with your issue since, again, the issue is on the server side.

from signalr-client-swift.

I am closing this issue because there is no work to be done on the Swift client side.

If you happen to play with the Embeddinator I would be very interested in your impression/results.

from signalr-client-swift.