Hi, I have a problem when trying to use server as ...

# rsocket

[langara]

Hi, I have a problem when trying to use server as requester. Maybe I'm configuring it all wrong (rsocket-kotlin as ktor plugin), but I get error:

Exception in thread "AWT-EventQueue-0 @coroutine#2874" kotlin.NotImplementedError: Request Response is not implemented.
	at io.rsocket.kotlin.RSocketKt.notImplemented(RSocket.kt:52)
	at io.rsocket.kotlin.RSocketKt.access$notImplemented(RSocket.kt:1)
	at io.rsocket.kotlin.RSocket$DefaultImpls.requestResponse(RSocket.kt:38)
	at io.rsocket.kotlin.RSocketRequestHandler.requestResponse(RSocketRequestHandler.kt:94)

[langara]

Also, maybe this is what I'm doing wrong?:
I'm using RSocket object I got inside fireAndForget lambda as "this", to later call requestResponse back from server to client.
Should I maybe use some other "alive" rsocket object? If so, how to get it?

[Oleg Yukhnevich]

Can you show some client / server configuration?
This error says, that your responder(request handler) doesn’t have requestResponse method of RSocket implemented

[langara]

My config is too scattered now, to share, but I can try to prepare some simple reproducer later.
It looks like the requestResponse called on server side doesn't even reach client side (I've enabled debug logging). The exception above is thrown on server side. I do configure acceptor { RSocketRequestHandler { requestResponse { ... } } } inside HttpClient. Can it be that I'm using "dead" RSocket object on server side?

[Oleg Yukhnevich]

Hm
What i really want to see:
1. acceptor on client
2. Acceptor on server
3. where and how request is initiated

[langara]

Ok, so looks like I fixed my issue, but I'm still a bit confused about how many different RSocket objects are there to use (let's say just on server side) and about their lifecycles. I wrongly assumed if there is only one connection started by one client, then there should be just one RSocket object on server side. So oryginally I used RSocket provided to fun RSocketRequestHandlerBuilder.fireAndForget block as receiver (and this lead to exception later when trying to use this RSocket object). The fix I now have is to ignore that RSocket, and use the ConnectionAcceptorContext.requester available (in less convenient place) earlier when I'm calling fun Route.rSocket. It works but I'm yet not sure if it's the right thing to do. I see there is yet another RSocket object available (or maybe it's the same) returned by: fun RSocketRequestHandler , so maybe I should use this one...

[langara]

Let me try to show it in code to be a bit more clear:

fun Application.simpleModule(...) {
    install(WebSockets)
    install(RSocketSupport) {
        server = ....
    }
    routing {
        rSocket(path) {
            val rs1 = requester
            val rs2 = RSocketRequestHandler(configure = myconfigure)
            rs2
        }
    }
}
....
fun RSocketRequestHandlerBuilder.myconfigure() {
    fireAndForget {
       val rs3 = this
       myregistrar(RemoteTreeBrowser(rs3, log))
    }    
}

So there are three vals: rs1, rs2, rs3. My question would be why so many, and when to use which. (it's all server side, and only one client is connecting)
My oryginal approach was to use rs3 and it throws exception later on when RemoteTreeBrowser tries to do rs3.requestResponse(...). Now I swapped it to use rs1 instead and it works, but still not sure if I'm doing it right / as intended.

[langara]

BTW it sounds like I'm complaining a lot, but generally I'm very excited about this library. So many great powerful technologies connected together: multiplatform + kotlin flows + rsocket protocol + coroutines with structured concurrency...

[Oleg Yukhnevich]

Overall, for each side of communication (client and server), there are 2 RSocket objects: requester(for doing requests) and responder(for handling requests)
Let’s take a look at your code:
• rs1 - is a server requester for doing requests to client responder
• rs2 and rs3 - are the same instances of server responder
rs3(this) is in scope of request handler mainly to pass CoroutineScope to request handling logic, f.e. to launch something in background of connection. You can directly implement RSocket interface, to archive this, but with small DSL it’s much more easier

Thx for good words!