configuration - How do I correctly configure a WCF NetTcp Duplex Reliable Session? -
please excuse obvious self-q/a, info misunderstood, , incorrectly answered. wanted place info here people searching definitive reply problem.
even so, there's still info haven't been able nail down. set towards end of question (skip if not interested in preamble).
how correctly configure wcf nettcp duplex reliable session?there many questions , answers regarding topic, , of them suggest setting inactivitytimeout="infinite" in configuration. doesn't seem work correctly, particularly case of nettcp (it may work correctly wsdualhttp bindings, have never used those).
there number of other issues associated this: including, channel not faulting after client or server unexpectedly disconnected, channel disconnecting after 10 minutes, channel randomly disconnecting... channel throwing exception when trying open... unable configure metadata on same endpoint...
information have figured out, through hard won trial , error.
infinite not appear valid configuration setting in situations (and certainly, visual studio validation schema doesn't know it). there 2 special configuration converters, called infiniteintconverter , infinitetimespanconverter sometimes work convert value infinite either int.maxvalue or timespan.maxvalue, haven't yet figured out situations in appears valid works, , doesn't. what's more, appears libraries allow infinite in config, while others not, can succeed in 1 part of configuration, fail in another. you must configure both inactivitytimeout , receivetimeout, on both client , server. while these values not have same, should cause confusion if not. (technically, can leave inactivitytimeout default value if want, should aware of value, , does) inactivitytimeout should never set big value, much less infinte or timespan.maxvalue. inactivitytimeout has 2 functions (and not understood). first function defines maximum amount of time can elapse on channel without receiving "infrastructure" or "operation" messages. sec function defines period of time in infrastructure messages sent (half time specified). if no infrastructure or operation messages have been received during timeout period, connection aborted. receivetimeout species maximum amount of time can elapse between operation messages only. value can set big value, such timespan.maxvalue (particularly if channel runs internally on trusted network or on vpn). value defines how long reliable session "stay alive" if there no activity between client , server (other infrastructure messages). ie, client not phone call methods of interface, , server not phone call client. setting short inactivitytimeout , big receivetimeout keeps reliable session "tacked up" when there no operational activity between client , server. short inactivity timeout (i maintain default 10 minutes or less) sends infrastructure "ping" messages maintain tcp connection live while long receive timeout keeps reliable session active. while @ same time providing reasonable timeout in case of disconnection. if set inactivitytimeout big value, reliable session not reliable has no way maintain tcp connection alive, nor have way verify integrity of connection. won't know if user has disconnected unexpectedly until seek , send message client , find out connection no longer there. why many people utilize infinite setting resort creating "ping" method in service, unnecessary if you've configured these settings correctly. if set inactivitytimeout value larger receivetimeout likewise unreliable, still governed receivetimeout operation messages. ie. if forget set receivetimeout , leave @ default 10 minutes, if user idle 10 minutes, connection aborted. when client or server unexpectedly disconnects (app crashes, network failure, trips on powerfulness cord, etc..), other side may not notice right away. have attached various channelfaulted event handlers in various test situations, , connection faulted right away... other times doesn't seem fault @ all. have discovered through trial , error when doesn't seem fault, fault after inactivitytimeout expires on end. (so if it's set 10 minutes, after 10 minutes phone call channelfaulted event). i have not yet figured out why in situations notices disconnection right away, , others waits timer expire. in both cases, notice internal first chance communication exceptions thrown , handled framework, , there calls abort connection... somehow phone call event handler gets lost , must wait timeout. suspicion somehow thread related. when trying configure metadata work across nettcp channel, have had sporadic results. works, doesn't. i've read many reports metadata doesn't work on nettcp , have utilize http channel metadata, have in fact had work on several occasions using net.tcp:// url generate proxy. alter something, recompile , no longer work. changing things back, wouldn't work again. confusing magic incantation necessary create metadata function on net.tcp, shared endpoint on same port (obviously different address). when configuring both nettcp , metatdata endpoint on same service, , specifying non-default settings connection parameters listenbacklog, , maxconnections, need create sure metadata endpoint uses same settings, typically means have define custom binding, since these settings not available standard tcp mex binding. includes setting listenbacklog , maxpendingconnections on tcptransport, , groupname , maxoutboundconnectionsperendpoint on connectionpoolsettings. the default setting ordered setting of reliablesession true. uses lot more overhead turning off. if don't need ordered messages, suggest turning off (need set on both sides) - configuration still need understand:
how correctly configure shared net.tcp metadata endpoint? (i add together illustration when chance) currently, i'm specifying http url bypass problem. it's inconsistent why works , not. kept getting error `the uri prefix not recognized' when generating proxy in visual studio.
why wcf fault channel upon disconnect, , waits inactivitytimeout expire? controls/causes 1 vs other behavior?
wcf configuration duplex-channel
No comments:
Post a Comment