No huge advantage in your case, other than eliminating the connection setup overhead for each request. However, that comes at a cost of having to deal with multiplexing the requests and responses from the server, and distributing them back to the relevant user of the webapp.
If you are extremely high volume, it *might* be useful. If not, it's probably not worth the effort. You can always implement it later if it turns out to be necessary. Rogan On Fri, Mar 17, 2017 at 3:55 PM Nicolas Ocquidant <[email protected]> wrote: > Thank you for your time. > > What would be the advantages of using a long alive TCP connection? > > Sorry, but I must say that I don't follow you. I am new to Netty (and > network in general) but my understanding is: > > WEBAPP (blocking) ------> MW-NETTY (async/non blocking) ------> SERVER > (blocking) > [http] [tcp] > > Then, for each connection initiated by the webapp: > - the webapp will wait for an answer, blocking a thread (not a big deal > right now) > - the mw-netty will instantiate a channel to the server (same event loop, > the inbound channel and the outbound channel are "linked", see HexDumpProxy > example) > - the server will reply using the opened tcp connection > - the mw-netty will reply using to the webapp using the opened http > connection > > So, according to me, it should work without using an ID. What am I > missing? > > --nick > > Le vendredi 17 mars 2017 09:53:22 UTC+1, Zhu Ran a écrit : > > Because you talk to SERVER via tcp, I guess that you actually want to use > a long-alive tcp connection to communicate with server, > but for WEBAPP ---> MW-NETTY communicating, you would rather to apply a > one-connection-per-request strategy, because > it is http protocol. > > First of all, I guess that you want to implement the middleware via my > advice in a previous topic in this discuss group. > In this way, you should guarantee that in the SERVER's response, there is > the id somewhere(in HEAD or BODY), so > you can get the right WEBAPP connection for each WERVER's response. > > Another thing you may what to do is you should parse the http request to > get the id. > Netty has afford some http utilities, you can consider the HttpServerCodec: > > > https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/HttpServerCodec.java > > Netty has also afford examples to show how to use it: > > > https://github.com/netty/netty/blob/4.1/example/src/main/java/io/netty/example/http/helloworld/HttpHelloWorldServerInitializer.java > > Good Luck! > > > On Thursday, March 16, 2017 at 5:08:09 PM UTC+8, Nicolas Ocquidant wrote: > > I implemented a middleware in Netty based on the HexDumpProxy example: > > BROWSER ------> WEBAPP ------> MW-NETTY ------> SERVER > [http] [http] [tcp] > > > The MW-NETTY (see above) needs to connect to the SERVER using a port > number different for each customer (the WEBAPP is dedicated by customer). > So, as a last resort, the TCP port could be disabled to preserve the > SERVER... > > The client id is transported in an HTTP header from WEBAPP to MW-NETTY. > As the channels are created before messages arrive, what would be the best > strategy? > > Thanks, > --nick > > -- > You received this message because you are subscribed to the Google Groups > "Netty discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/72eb6b6a-4f8e-4795-813d-c10864d1bf4a%40googlegroups.com > <https://groups.google.com/d/msgid/netty/72eb6b6a-4f8e-4795-813d-c10864d1bf4a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Netty discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAOYdKdj3eMS%3DLLRSLyyWdE8%3DDTfoBVAMJ6yinObtLJ0OnLmGfQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
