Azure Service Bus relay response slow - wcf

I've a Azure Service Bus Relay hosted in Azure which exposes the end point similar to one below:
https://myTestSB.servicebus.windows.net/MyService/LogIn()
Interestingly when I make a call to this service bus, it makes 4 calls as shown below.
This is causing the slow response.
Could someone
clarify what's happening
on each call? Does first call #1 have to wait for 2, 3 and 4?
1 (Takes long time)
GET https://myTestSB.servicebus.windows.net/MyService/LogIn()?$filter=UserID eq '1234' and Password eq 'secret'
User-Agent: Microsoft ADO.NET Data Services
.....
Status Code: OK 200
...
2
CONNECT https://myTest-sb.accesscontrol.windows.net/WRAPv0.9/
Status Code: OK 200
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
3
POST https://TestSB-sb.accesscontrol.windows.net/WRAPv0.9/
Content-Type: application/x-www-form-urlencoded
Host: TestSB-sb.accesscontrol.windows.net
Content-Length: 307
Expect: 100-continue
Connection: Keep-Alive
Status Code: OK 200
.......
4
CONNECT https://myTestSB.servicebus.windows.net/MyService/LogIn()?$filter=UserID eq '1234' and Password eq 'secret'
Status Code: OK 200
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
It takes 5-10 seconds for logon Service Bus which only takes less than a second on on-premise environment. Not sure why and how Service Bus is adding delay.

By default, the Azure Service Bus Relay typically uses an opt-in authentication via ACS (Access Control Services). In order to consume the relay endpoint - it must first authorize the WCF Channel using an ACS token. The extra calls you are seeing could be removed via configuration if you choose not to use ACS as you are providing your own relay access control.
Disables ACS for Service Bus Relay (Opt-Out)
<bindings>
<netTcpRelayBinding>
<binding name="default">
<security relayClientAuthenticationType="None" />
</binding>
</netTcpRelayBinding>
</bindings>
For more details, see MSDN on securing Azure Service Bus Connections.
As for the latency issue (5-10 seconds) - this all depends on the number of WCF Calls used, where you are in relation to the data center, and how much data is being shared. There are numerous options to tune all the above. Also ensure you have configured your firewall properly for establishing Azure Relay communication.

Myagdi, are you using the WebHttpRelayBinding for both the service and the client? What is the version of the SDK you are using?
Note that when you use the Service Bus Relay there are 2 layers of authentication that occur. The client has to first authenticate to the Service Bus Relay endpoint using ACS, and then perform any application-specific authentication against the on-premises WCF service.
The additional traffic that you are seeing is due to the client acquiring a token from ACS to authenticate to the Service Bus Relay. Now, by default, the lifetime of the token issued by ACS ranges from 20 mins to 3 hours. If you are using our .NET SDK, then in most cases, the client will cache the token for the duration of its lifetime. Hence subsequent requests to the Relay endpoint during this token lifetime should not result in this additional exchange with ACS for token-acquisition.
Also, due to the Service Bus Relay design, the first request from a client to a listener service generally incurs higher latency, due to control communication. The latency is generally lower for subsequent calls.
You can contact me at #santoshc1 if you have additional questions/issues.

Related

Disable Blazor Server Kestrel keep-alive client-server communication

I'm about to create a .net 6 Blazor server application hosted by Kestrel (within a docker container) which uses a custom timeout handling on client side. Once the application is not used for e.g. 30 minutes a dialog is displayed and the page needs a reload for further usage (and a new server connection).
For stopping the application (connection) I call "Blazor.disconnect();" on the client side.
This works in general but I've noticed that after calling Blazor.disconnect() and displaying the information message the client and the server are still exchanging keep-alive data like this which I also want to suppress to save resources and bandwidth:
Sent a ping message to the client. [Microsoft.AspNetCore.SignalR.HubConnectionContext]
Sending payload: 3 bytes
[Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport]
Message received. Type: Binary, size: 3, EndOfMessage: True [Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport]
Is there a way to end this communication on client side (via JavaScript) or on server side without having to navigate away from the application page ?

Can WCF duplex service be used to call client when client is offline?

Is it possible a service to call client after 4 -5 days when client is offline? e.g.
1. The client request some reports through service.
2. Service updates database with client request.
3. Offline work is done on the request
4. Report is uploaded to the database.
Can we service call its client and send report as soon as report is uploaded to database?
Can WCF duplex service be used to call client when client is offline?
Yes. WCF can be configured to use MSMQ as a transport. MSMQ is the only WCF transport that allows for all three:
disconnected scenarios
resume when computer becomes online and
optionally provide a level of guaranteed delivery
MSDN:
If you need to support disconnected queuing, use netMsmqBinding. Queuing is provided by using Microsoft Message Queuing (MSMQ) as a transport, which enables support for disconnected operations, failure isolation, and load leveling. more...
Essentially you invoke a WCF method (send a MSMQ message) and it will be delivered when the computer comes on-line again. Assuming you have set the appropriate expiration options.

Request/response messaging pattern - Azure Service Bus

All ,
I have a doubt on the Request response pattern... Assume the following is my scenario
1.I have a service running on Windows Azure. This service can be called by users to execute a command.
2.I have a client applications that is running on my intranet. This client application will execute the command . The computer in which the client application is running is connected to internet , but does not have a static IP i.e machine cannot be accessed directly via the internet
3.I am planning to use Azure Service Bus through which my service on Windows Azure can communicate with the client application to execute....
In this scenario, can i use Request/response messaging i.e can the service post a message and expect a response from the client
OR
Should i use command queue for each client , the Service will push the command to be executed on a queue , the client will poll the queue and execute a command
Any help is appreciated
Since you are using WCF (based on the tag), you should consider using Service Bus Relay calling the WCF service asynchronously.
I assume you want to use Relaybinding here, using WCF.
Your web service (which is behind NAT, firewall devices, etc) is only opening outbound connections in that case. The service is listening on a registered endpoint in the cloud (that is accessible for him, because of credentials and protocol). All incoming service calls are sent over that port/socket. The response will then be sent back over the outgoing port again.
If the IP Address of your service changes, it wil register itself again (by listening on the same registered endpoint) and you can reach that service transparantly.
Another way you can achieve request/response in an asynchronous fashion, is through queues. This does not require any open connection between your client and your service and can happen fully asynchronous. This can be achieved by sending a message to the request queue for your specific service (with a Correlation Id). And when that service has processed that message, it can send the response to the response queue of your application, using sessions. A good example of this pattern can be found on Alan Smith's blog: http://www.cloudcasts.net/devguide/Default.aspx?id=13051

WCF client service communication

I have a very basic question about wcf service with basicHttpbinding:
When client calls a wcf service(basichttpbinding) synchronously how the request and response is received between two? Does a socket connection established between 2 and port on server tied up till response is received on client? How the response is sent back to the waiting client? IF port on server is unusable for long running operation then will it hinder service ability to accept request from other client? Also, how communication happens in can of asynchronous call to wcf service? I read that channel and hence port/socket should remain open at both ends.
With basichttpbinding, it's much the same as normal http communication between a browser and a web server. If you hit a link on a web page, a request from the browser is sent to the appropriate web server, which processes the request and returns the content, as a response, to the waiting browser.
It's the same with WCF basicHTTPBinding. The WCF client sends a post or get request to the designated web service (http: //webservice:port/ServiceObj/MethodName) and waits for a response. When the web service finishes gathering the data, the data is sent back to the client in the response on the open connection, which is then closed by the host. There's no persistant connection. Thus, basichttpbinding is stateless. Once the web service sends the response, connection is recycled and the service is ready to go for the next request.
If the client is finished with its communication, it can close its connection explicitly; that's best. But if it doesn't close its connection, it won't make any difference to the host.

Multiple MSMQ communication in WCF

I am using a client server application in which client send request to server in request queue, server receive this request object from queue process it and send response in response queue which is received by client application. I want same functionality in wcf service and client so whether I need to create two different end points for both msmq and if yes than how same client will work with both endpoints.
You should not think of it as strictly a client server application.
You do have a request originator referred to as client and a request processor referred to as Server,
but when thinking WCF- client is the one sending the message, server is the one receiving. Meaning that in WCf terms, at first your client is really a classic "client" and the server is really a classic "server". But when you get to the point after the original request is processed and needs to be sent back- the roles are reversed! the server becomes a WCf client and the client becomes a WCf server.
What this means is that you processes need to expose a separate endpoint for each other. The server listens on a certain EP for incoming messages (requests), and the client listens on a certain EP for incoming messages (responses).
Hope this clarifies things a bit.