All
Sorry if this is an obvious question but does WCF streaming work correctly from a client to an web server (using basicHttpBinding) if a proxy server is in the way?
I seem to remember reading that proxy servers can cache requests until they are ready (hence why sometimes a download doesn't respond for ages then suddenly completes) and I'm not sure if this will stop streaming working correctly.
Thanks
Probably too late for you, but from my interpretation of the web page below- no, streaming does not work when a proxy server is in the way.
http://msdn.microsoft.com/en-us/library/ms733742.aspx
The decision to use either buffered or streamed transfers is a local decision of the endpoint. For HTTP transports, the transfer mode does not propagate across a connection or to proxy servers and other intermediaries. Setting the transfer mode is not reflected in the description of the service interface. After generating a WCF client to a service, you must edit the configuration file for services intended to be used with streamed transfers to set the mode. For TCP and named pipe transports, the transfer mode is propagated as a policy assertion.
Related
Hi I am new to Marklogic and Apache. I have been provided task to use apache as loadbalancer for our Marklogic cluster of 3 machines. Marklogic cluster is currently running on Linux servers.
How can we achieve this? Any information regarding this would be helpful.
You could use mod_proxy_balancer. How you configure it depends what MarkLogic client you would like to use. If you would like to use the Java Client API, please follow the second example here to allow apache to generate stickiness cookies. If you would like to use XCC, please configure it to use the ML-Server-generated or backend-generated "SessionID" cookie.
The difference here is that XCC uses sessions whereas the Java Client API builds on the REST API which is stateless, so there are no sessions. However, even in the Java Client API when you use multi-request transactions, that imposes state for the duration of that transaction so the load balancer needs a way to route requests during that transaction to the correct node in the MarkLogic cluster. The stickiness cookie will be resent by the Java Client API with every request that uses a Transaction so the load balancer can maintain that stickiness for requests related to that transaction.
As always, do some testing of your configuration to make sure you got it right. Properly configuring apache plugins is an advanced skill. Since you are new to apache, your best hope of ensuring you got it right is checking with an HTTP monitoring tool like WireShark to look at the HTTP traffic from your application to MarkLogic Server to make sure things are going to the correct node in the cluster as expected.
Note that even with the client APIs (Java, Node.js) its not always obvious or explicit at the language API layer what might cause a session to be created. Explicitly creating multi statement transactions definately will, but other operations may do so as well. If you are using the same connection for UI (browser) and API (REST or XCC) then the browser app is likely to be doing things that create session state.
The safest, but least flexable configuration is "TCP Session Affinity". If they are supported they will eliminate most concerns related to load balancing. Cookie Session Affinity relies on guarenteeing that the load balencer uses the correct cookie. Not all code is equal. I have had cases where it the load balancer didn't always use the cookie provided. Changing the configuration to "Load Balancer provided Cookie Affinity" fixed that.
None of this is needed if all your communications are stateless at the TCP layer, the HTTP layer and the app layer. The later cannot be inferred by the server.
Another conern is if your app or middle tier is co-resident with other apps or the same app connecting to the same load balancer and port. That can be difficult to make sure there are no 'crossed wires' . When ML gets a request it associates its identity with the client IP and port. Even without load balencers, most modern HTTP and TCP client libraries implement socket caching. A great perfomrance win, but a hidden source of subtle random severe errors if the library or app are sharing "cookie jars" (not uncomnon). A TCP and Cookie Jar cache used by different application contexts can end up sending state information from one unrelated app in the same process to another. Mostly this is in middle tier app servers that may simply pass on requests from the first tier without domain knowledge, presuming that relying on the low level TCP libraries to "do the right thing" ... They are doing the right thing -- for the use case the library programmers had in mind -- don't assume that your case is the one the library authors assumed. The symptoms tend to be very rare but catastrophic problems with transaction failures and possibly data corruption
and security problems (at an application layer) because the server cannot tell the difference between 2 connections from the same middle tier.
Sometimes a better strategy is to load balance between the first tier and the middle tier, and directly connect from the middle tier to MarkLogic.
Especially if caching is done at the load balancer. Its more common for caching to be useful between the middle tier and the client then the middle tier and the server. This is also more analogous to the classic 3 tier architecture used with RDBMS's .. where load balancing is between the client and business logic tiers not between business logic and database.
We have WCF service X: deployed on server A and Server B, host address:
http://127.0.0.1:8777/ServiceX/
And we load balance the two servers. We accesss the service via http://myappserver/ServiceX
We need to use per-session mode, and we set [reliable sessions] as true:
We don't find any issue till now based on testing. But the below linked MSDN article says that Do not use reliable sessions for Load Balancing with the WSHttp Binding? Please can someone give more details? Thanks a lot.
WCF Load Balancing http://msdn.microsoft.com/en-us/library/ms730128.aspx
Reliable Messaging means all your messages from your established client reach the same endpoint behind any intermediaries like routers and load balancers.
Load balancing means your calls will be distributed across all nodes as the load balancer sees fit.
Those two goals are mutually exclusive. You can have one or the other, not both.
I have not had time to try this myself yet, but I found this old blog entry (https://blogs.msdn.microsoft.com/drnick/2007/07/13/sticky-sessions/):
This division according to groups would allow a feature like reliable messaging to work because the same server would be used to process all of the messages in the reliable session. The feature that this division method represents is typically called “sticky sessions” or some other phrase for affinitization in the load balancer.
Given that you mention that your firewall supports sticky sessions, I suspect/hope you will be fine.
After developing mini project with WCF duplex (Chat Service | Sms Service), I got a Point that maybe not be correct!!
I believed Duplex theory is good and useful but there is a lot problem about using Wcf Duplex. (like reliable session, Time-out exceptions, Client address-Management on server side, proxy management on Client Side)
am I think wrong ? am I miss something?
For more Information I Used wsDualHttpBinding not tcpBinding.
If you need bidirectional communication and you want to use WCF, duplex channels are the way to go. You just need to design your application correctly and correctly handle all problems you have described. If you feel that these problems are overhead and make things even worse you can always use network programming directly (sockets) or handle bidirectional communication by yourselves exposing separate service on server and another on client (where first call from client inform server about clients address) - this scenario will suffer from the same communication problems as WsDualHttpBinding.
WsDualHttpBinding itself is special kind of duplex communication. I personally don't like it because people very often misuse it. The problem is that this binding uses two separate connections - one from client to server and second from server to client. That is big difference to net.tcp where only connection initiated from client to server is used. Obviously using WsDualHttpBinding over internet (= you don't have control over client machines) becomes much more complicated because each client must configure its firewall (in computer, on home internet gateway, etc.) to allow connection on some port. Also if you want to run more then one instance of application on the same client machine, each instance must use its own port.
I'm developing a synchronization service using WCF and Sync Framework, and I have it working when the endpoints can communicate directly.
The next step I need to implement is to synchronize 2 endpoints where they both are behind routers and the router ip is changing constantly. I am thinking about a publicly available intermediary that should forward the calls between the 2 endpoints. My biggest problem is that I cannot rely on the users to configure the port forwarding on routers so I cannot directly open a connection from the other endpoint or the intermediary.
My idea is based on FogCreek's CoPilot, and other remote assistance solutions (LogMeIn, TeamViewer, etc) which works without any router configuration.
How would you implement it?
You need something like relay in Azure. I would try implement it this way:
Your intermediary will provide two operations:
Push - client will call this operation when publishing new data for synchronization. Data will be stored on service until other client downloads them.
Pull - client will call this operation regulary to download any published data stored on intermediary.
Routers with changing IP should not be a problem, because client will be always initiating connection.
If you are not limited to HTTP protocol you can implement this with Net.Tcp binding and use duplex communication. In such case your intermediary will be able to forward synchronized data immediately. But this solution can have additional complexity when dealing with sessions and connections.
In my application I need to push notifications of real time events from server to clients. The amount of data to pass is very small, mostly and Id. The number of clients listening simultaneously can be around 100 and I may have to publish one notification every 2 - 3 seconds. Both the server and client are built using .Net and WCF.
Given these requirements I have built a set of WCF services which will be run on a load balanced server cluster. The Instance context mode is Per Call and there is no need for sessions etc.
I am currently using BasicHttpBinding. Will TCP binding be better? Does it run on IIS 5 or 6? If not why?
What configuration for serialization can work best?
What are the things I need to do to make sure I get maximum performance?
Edit - Adding more information based on some of the responses -
I host a small WCF service in the client process using manual hosting. The server just calls this service on each client to push the data to all of them.
Firstly have you considered using messaging for what you are trying to achieve?
In answer to will TCP binding work better than BasicHttpBinding- almost certainly yes. If you want to use TCP, you can't use IIS- look into WAS with Windows Server 2008. If you're stuck with Windows Server 2003, then you'll have to host in a windows service instead.
You've made a good choice by choosing per call- this is the preferred instance management mode for creating scalable WCF services.
Edit:
Now you've update your question, I recommend you take a look at IDesign's Pub/Sub framework if you want to stick with WCF. I'd also look at Pub/Sub with MSMQ in WCF and also with "Vanilla" products such as Tibco RV.
If you need pushing data from service to clients you need sessions and you need duplex binding - NetTcpBinding or WSDualHttpBinding. It will not work with BasicHttpBinding because it allows only pulling data (client pools the service for changes). Push data means tha service sends data to clients when needed.
NetTcpBinding always crete session. It can't be hosted in IIS 6 or older. NetTcpBinding is allowed only in Windows Activation Service (WAS) which is extension of IIS 7.x. For older systems you need self hosting = windows service.
Edit:
Based on your description you need Publish-Subscribe message exchange pattern.