I want to open a connection back to the server using Flex so I can stream chat messages to the Flex front-end. How do I do this and does Flex enforce any same-origin restrictions on ports or subdomains?
You'll have to use a messaging server software and then use the Producer and Consumer classes in the Flex framework to send and receive messages.
What you need depends on what server you are running on. If you are on a Java stack, you can use BlazeDS and ActiveMQ.
If you are streaming/consuming from and to different domains, you'll need to setup a crossdomain file that allows the inter-domain communication.
Related
I am writing a blazor server application.
I have a textbox+button in a page and a grid. What i want to do is to allow users to type some text in the texbox. The text should be added to the grid.
What i want is to automatically refresh grid on all browsers when a new message is typed.
I have tried and manage to do that with signalr and signalr hub. It works like a charm.
But i am wondering something: Blazor server creates a signalr connexion between server and browser. My signalr hub is creating a second signalr connexion.
Is there a way to do that without creating a second signalr connexion.
In other words, is there a way to send notifications to browsers without a signalr hub ?
Thanks
I don't know if my view of your problem is correct.
I suspect you're trying to create a direct Signalr connection point-to-point between clients, without any centralized hub.
Right?
If this is the case I think it's impossible using only Signalr, because the server maintains a list of clients ip/port connected to the hub and this list isn't shared between clients.
I don't know if there is any kind of project based on Signalr that enable a Blazor WASM application to expose itself as a server in order to receive communication directly from other WASM Client, but in the world of gaming all is possible !
I need to develop an application which would run in a corporate network. The client should both receive commands (shutdown, restart, ...) and send info (something happened, ...) from/to the server. So, using a web interface, the network administrator would be able to see what clients are connected, send commands to them, and see real-time info coming from them. The client should be written in Delphi (normal VCL forms with Edits, etc.) and the server "preferably" in ASP.Net.
I researched a bit and I think WebSockets might be good to achieve this. I plan to use some WebSocket libraries for Delphi like this. I'm not sure what technology I should use for the server.
Please tell me if WebSockets is good for my requirements. Other solutions are welcome (maybe writing the server in Delphi?).
Web interfaces typically are HTML based views, and require a web HTTP server and a web browser (Chrome, Firefox, etc.). Delphi Web Socket client libraries however can only be used to talk with a Web Socket server from within a native Delphi application, for example a VCL GUI.
If you plan to write a VCL application (not web browser based), you have other transport protocol options besides Web Sockets, which are widely used in small and large systems:
MQTT (formerly Message Queue Telemetry Transport)
STOMP (Streaming Text Oriented Messaging Protocol)
AMQP (Advanced Message Queuing Protocol)
MSMQ (Microsoft Message Queuing)
As with WebSockets, these protocols offer asynchronous / bi-directional messaging. On the server side you can choose from many production quality implementations of these protocols (known as 'message brokers'), mostly free / open source. Similar to HTTP, message payload can be anything - text or binary data - and messages can use headers to provide application-defined metadata.
Your server-side application code can be written in Delphi, and is only another client of the message broker, communicating with the client applications over the message broker protocol. As soon as client and server are connected to the message broker, messages can flow in both directions.
Many advanced features are included in message brokers: if a client disconnects while the server is still sending messages, the message broker can store these messages and deliver them as soon as the client reconnects.
For most of these protocols I have seen client libraries or wrappers for Delphi / Object Pascal, free and open source or commercial.
I have a use case where we will have an ASP.NET MVC Server Application but it needs to talk over a persistent connection to a Windows service. It doesn't look like SignalR does this as it really wants talk Server to JavaScript browsers but I did notice .NET desktop libraries. Can it talk from a server to a Windows server? If not, is there a recommended way, TCP/IP or HTTP to have a persistent connection between the two? NetTcpBinding in WCF?
Yes, there is a SignalR client library for .NET that you can use in any old .NET app to talk to a SignalR server just like you can from JavaScript.
While there is a WebSockets binding for WCF, there is no binding that actually talks native SignalR which adds its own message framing on top of raw web sockets. So, while possible, it doesn't exist today and I wouldn't hold my breath for it ever being created.
Why not simply have a queue using RabbitMQ. And anytime the web need to talk to window service, it push a message into the queue while the window service listen to the queue
I'm creating a client-server game. My client is a flex based game, and my server is erlang server.
At the beginning, when I test directly my flex client in flash player, I can establish a connection easily to my erlang server through socket connection. And both can exchange data with no problem.
The problem rise when I deploy my flex app at Apache http server, and running it using a browser by calling http://localhost/ ... my flex socket sends message requesting for a crossdomain policy to my erlang server.
So I create an xml message that represent a crossdomain policy, and send it back to my flex app as a response for that request.
Yet still I can't establish any permanent socket connection between my flex client and my erlang server. I know this because I add listener on my flex socket that will modify its internal state to CONNECTED, if a connection between client-server has established.
I haven't experienced the problem but maybe this would help.
The default policy file is named
crossdomain.xml and resides at the
root directory of the server that is
serving the data...
You can use the loadPolicyFile() method to access a nondefault policy file.
http://livedocs.adobe.com/flex/3/html/help.html?content=deployingoverview_12.html
A policy file served by an XMLSocket
server has the same syntax as any
other policy file, except that it must
also specify the ports to which access
is granted. When a policy file comes
from a port lower than 1024, it can
grant access to any ports; when a
policy file comes from port 1024 or
higher, it can grant access only to
other ports 1024 and higher.
http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00005403.html
The flashplayer restricts your socket usage in several ways. One you already found out :) The other is to specify whether you use the network or not. There is a networking mode and a file system mode (access to the filesystem). You can't have both.
So you should try to compile it with this:
-use-network=true
And yes I know it's a PITA doing socket programming with flash. You should implement every OnErrorXYZ method and print as much information as possible. Using wireshark or a different network sniffer is also a good idea.
As far as In understand the Flex technology, a Flex client connects to a Flex server to retrieve business information. Is this the only allowed connection for the client, back to the originating server? Or can a Flex client also open a secondary connection to a different server wich runs BlazeDS for message exchange? (This might offer an option for load balancing and cross-platform development).
Update: thanks for the answer! I have found this page which links to the Cross-domain policy file specification:
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
Yes, a Flex client can connection to a variety of servers, including BlazeDS. What could prevent a client from conenctiong to a BlazeDS server is the crossdomain.xml, which is a connection policy document hosted on the server.
I've got one concern about your question, and that is using the term 'Flex server'. That was something folks talked about with Flex 1, circa 2005! Adobe is now on Flex 4, and some relevant server technologies/platforms/software/protocols of interest are BlazeDS, Red5, FMS LiveCycle Data Services, JSON, AMF3, etc.
If BlazeDS is your main server side endpoint and your primary goal is load balancing then you may want to explore the clustering capabilities of BlazeDS -- http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=services_clustering_1.html.