Yup again dead on. The client could open its own non HTTP socket. And you're also right. HTTP isnt the best medium for this stuff. The problem is with the network admins and security dudes at all these companies.
Here is the problem.... What port are you going to use? See most corporate firewalls only allow outbound sockets on 80 and 443. You cant use those ports. The server is already listening on them. So your choices are use some other port and risk that manay clietns just wont work. Youre other choice is to have the event handler managed by another server. You now have the sandbox issues to work around. I'll leave out the fact that it also means writing your own server. Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY x85 --- In [email protected], "Eric Raymond" <[EMAIL PROTECTED]> wrote: > > My comments below. Sorry about the large amount of quoted text, but > it provides the contxt for the responses. > > Summary: You can accomplish the exact same functionality as a > HttpService being held open for a single response from the server with > a a client initiated socket which is held open. The nice thing aboiut > the clinet initated socket is that it can handle multiple "messages" > over time while the HttpSerive can effectively only handle one response. > > --- In [email protected], "Dave Wolf" <[EMAIL PROTECTED]> wrote: > > First off, this design makes a somewhat crazy assumption that client > > are able and willing to accept inbound data transmission. Not only > > does it assume the "client/consumer" can handle this, it also assumes > > that the network allows it. Thats where this all falls apart in a > > hurry. How many network admins allow random inbound sockets? <smile>. > > This might work OK in an intranet app, but it is wholely unsuited for > > wide networks. > > > There is absolutely no reason why the client cannot initiate the > connection to the server via a socket. In effect this is what you are > doing with HttpService. > > > > > > Lets assume that show stopper didnt exist. Now we enter into a pretty > > serious quality of service issue. See architecturally we have a > > consumer who is extreemly interested in the delivery of an event. We > > also have a producer who owns the onus of delivering that event. > > Whenever you have two parties with concerns that disperate you are > > asking for issues. > > > > For instance. We all know how dependable our networks are right? > > sarcasm intended>. Lets say the servant has a list of clients to > > deliver an event to. Now it rolls through its list of clients, but > > client37 is unreachable. How long does the servant try to deliver the > > event? Eventually for perfomance reasons it needs to give up. But lo > > and behold, moments after giving up on client37 his network issue > > resolves itself. Guess what. Client37 has no idea that an event got > > delivered and that event is gone. Client37 will, like a dumbo sit > > there forever thinking maybe... just maybe that event will show up. > > > > Flex is about building enterprise apps. These kind of QoS issues > > simply arent acceptable. > > > > The blocking registration pattern solves both issues. All sockets are > > outbound (I know you think this is hijacking HTTP but again, how many > > *corporate* firewalls allow even outbound sockets besides HTTP on 80 > > and 443) so we have no firewall issues. Since the client has opened > > the socket, if the network drops, so does that socket. So does then > > marshalling back from the servant. This means there is no undue load > > on the servant. It also means when the network returns the client > > simply opens a socket back and boom, gets the event. Basically if > > coded correctly in your servant, you have nearly guaranteed delivery. > > You also now accomplish this with no polling, so no network overhead, > > and if wanted for performance, the servant can timeout http sockets > > itself. Now the consumer simply has his http call in a loop, and > > connects back. It can be quite elegant. > > You can use this same pattern with a user initiated socket. Client > connects to server and waits for the server to send back message the > client is subscribed to. The beauty of sockets (over httpservice) is > that the socket does not need to be closed in order for the client to > process the results. So a socket could handle multiple requests per > connection. > > I think this is not a matter of functionality. Socket capabilities > are a superset of HttpService assuming you use them in the same manner. > > To me the issues come down to ease of development (HttpService wins), > , ease of deployment (HttpService wins) real world network issues > (HttpService wins), and performance/load handling (socket wins?). > > My guess is that HttpService will bog down north of 100-200 > connections per server while a good socket implementation will get you > north of 1-2K connections. (The socket server guys publish number > like this.) > > Can anyone speak to this in detail or point to something that we could > read? > ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
