Making DotNetty synchronous?

[kouweizhong]

Blocking request/response with DotNetty?

[nayato]

Blocking is fine as long as it is not on the executor thread. By default, work within Channel is executed on executor thread. If you were to block there waiting for response, you would also prevent any call to this channel to go through - including arrival of the response you'd be waiting for.
That said, it is fine to block outside of executor thread - just make sure that is the case. Also, DotNetty does not provide request-response model OOTB (due to tight dependency on protocol being used, etc.) meaning you'd have to code it up yourself.

[ovflowd]

@nayato i agree with @kouweizhong . Is nice implement a synchronous version for DotNetty, without removing asynchronous implementation. Some softwares, being more specific, some games, implement a reactive client<=>server communication, that means, (as i'm absolutely certain you know), the client send a request to server, and the server will answer to the client the a relative data corresponding to the requested "packet". In these games, the client does only one request per answer. That means the client will not do a request about other data without the server answer something. Also in the specific game that i'm describing, if the server answers a packet with a non satisfying structure (packet based in Data Models) with valid data, the connection is terminated. (for games that necessary to avoid bots, hacks, dos, and scripting tools..), or if the server doesn't answer a timeout (in some milliseconds are made)..

The communication in almost scenarios is really fast, that can, if you do an eye-seeing, asynchronous. I think synchronous implementation is good, since this make a total reactive way, where DotNetty doesn't expect other request while a response isn't sent. Also will be more secure for thread joins, where you can have more combinations scenarios, as example, only one global thread, or one global thread and one sub-thread per client (bad), or X global threads, and X total threads for clients, or multiple threads per client, or what else. Since the joining and the sync is more secure and faster, since doesn't exists other jobs (or handlers doing other jobs) for multiple request processing for multiple answers..

Other thing that i see in DotNetty, is the EndPoint to IPv4 casting (conversion), give (some times) IPv4 address with (weird) characters after the IP ends.

Also DotNetty identificates a client not by the address, but by the connection. I saw you can also get a handler per pipeline and not per connection. Okay, this discussion isn't on-topic here..

But yes i think a synchronous way is good.

[nayato]

as I said, there's no way to have blocking done in DotNetty itself. And back on topic - Request-Response is tied to your protocol - the fact that message coming from server is a response to a particular request is either defined by protocol limitation of not having more than one outstanding request message or by correlating response message with request by some ID. There's no universal rule. Once you have your req-rep implementation - by all means, feel free to block there, just make sure your code runs outside of executor thread.

[ovflowd]

Yes, the way of how the data is treated or handled or collected is job of the developer that uses the library (in this case DotNetty).. i really don't know if exists some gains of abling synchronous way.

I know really often about communication and socket libraries of how this is done..

But thanks for the clarifying.

[kouweizhong]

@nayato How DotNetty achieve synchronization? Thanks.

[nayato]

@kouweizhong, sorry missed this. In DotNetty (by default) all the work related to one connection is done on a single thread. That allows to safely say that there's no concurrency due to parallel execution. Many channels can be assigned to a single thread (executor).
If you want to do a request-response and just wait for it to complete - that's outside of DotNetty's functionality (at least for now). You would need to do it yourself, e.g.:

1. create TaskCompletionSource<MyResponseType> (promise) to give out to user waiting for the response.
2. associate promise with request id (packet id, etc. - depends on the protocol).
3. send out request, e.g. channel.WriteAndFlushAsync(request);
4. have a Channel Handler in pipeline that will listen for response(s).
5. once response arrives, this handler would find a related request/promise and complete promise with the response object / contents.

[kouweizhong]

@nayato Thanks！