Re: websockets questions
Andre, if you happen to use the Spring Framework already, we have a milestone release (version 4.0 M1) that provides fallback options based on the SockJS protocol. The next milestone 2 due in a week will provide higher level (sub-protocol) support for messaging patterns such as pub-sub and point-to-point. Rossen
Re: websockets questions
Howard W. Smith, Jr. wrote: On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil goupilpie...@gmail.comwrote: Regarding browser support, a framework like Atmosphere handles pretty well having WebSockets when they are available and falling-back to another Comet implementation (such as long-polling or http-streaming) when they are not. agreed, but I think the goal/desire, here, is to not use Atmosphere. Correct. In truth, we're not sure that we want to use Tomcat either. We're still one level remote of thinking of any implementation, and trying to understand 1) how exactly websockets works 2) if that general technology is, today, sufficently mature and stable for us to develop an application based on it, or we should wait another 6 months, a year,.. We know that there are a series of web application frameworks which support websockets. Unfortunately, these are not frameworks which we are using right now, and we don't really want to change our tools in the middle of the river. We also know that there are a number of organisations which already use it in production. But we are a small outfit, and the fact that Google may be using it (with a backup team of 50 developers to shore up their implementation) does not really help us. The reason why I put this question on the Tomcat users list is because it is a list I'm subscribed to, because I know that it is a good-quality list with little noise, because I know that Mark and Rainer are - to various degrees probably - involved in Tomcat support for websockets. So I figured that there was some solid knowledge of the protocol available here. I am also on the Apache httpd list, and I've done some searches on the WWW in general, and for the moment the general information available on websockets seems otherwise a bit scarce. This being said, the information already gathered here on this list tends to vindicate my posting on it. It has already cleared up a number of points for us, and added a couple of questions which we did not think of asking. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
On Fri, Jul 5, 2013 at 3:40 AM, André Warnier a...@ice-sa.com wrote: We're still one level remote of thinking of any implementation, and trying to understand 1) how exactly websockets works Most websocket implementations (RI/glassfish, atmosphere, tomcat, etc...) are open source, so diving in the code is definitely an 'option' for understanding how websockets work. 2) if that general technology is, today, sufficently mature and stable for us to develop an application based on it, or we should wait another 6 months, a year,.. honestly, I think it is sufficiently mature, since websockets are becoming the trend (incorporated in RI/glassfish/JavaEE7, I've seen recent tomcat 7.0.35+ releases that had websocket changes, no need to mention how 'alive' atmosphere is...smile). i think it is more a question of feasibility for you and your team to join in on the trend/fun... But we are a small outfit, and the fact that Google may be using it (with a backup team of 50 developers to shore up their implementation) does not really help us. funny. google's backup team of 50 developers versus how many open source developers using/coding atmosphere, tomcat, glassfish-websockets (grizzly?). :) The reason why I put this question on the Tomcat users list is because it is a list I'm subscribed to, because I know that it is a good-quality list with little noise, because I know that Mark and Rainer are - to various degrees probably - involved in Tomcat support for websockets. +1 for the moment the general information available on websockets seems otherwise a bit scarce. true, but websocket open source code is plentiful and available. :) This being said, the information already gathered here on this list tends to vindicate my posting on it. It has already cleared up a number of points for us, and added a couple of questions which we did not think of asking. Thanks. IMO (or maybe based on fact/history), not much chatter about websockets on tomcat user list, but if you find your way to atmosphere google groups mail list, there will be plenty of chatter over there. I will not encourage you to venture over to atmosphere google groups and ask questions such as this, since I'm sure the desire/goal over there is to post topics related to 'using atmosphere and any questions/issues while attempting to use atmosphere and atmosphere's trunk (latest version(s))'. i'm definitely someone that love to use latest versions of open source software. sometime ago, when I migrated from glassfish to tomcat/tomee (so I could do websockets, um, more effortlessly in my web app), I came across the fact that Jeanfrancois (Atmosphere developer/committer) had something to do with the websocket implementation in glassfish/RI, i think it is called grizzly, but I could be wrong. I'm not as versed with glassfish/RI as I used to be..when I was a glassfish 'user'. :) FYI, at the moment, i'm not writing low level websocket client/server code; i'm using PrimeFaces Push only/entirely, which is PrimeFaces + atmosphere. :) definitely not trying to encourage you to use a certain framework; one thing I like about Tomcat list is that there is a wide range of topics that I can listen to and/or chime-in on, when interested and when feasible. :) I love this user community (mail list).
Re: websockets questions
I'll just add a little bit of info (and guesses) below. Jess Holle wrote: Unfortunately I don't have any information -- just related questions. 1. For someone currently using Apache httpd+mod_jk to load balance requests, what does one do about load balancing WebSockets requests between Tomcat instances? * As Andre alluded to, the only mention of websocket handling in Apache httpd really appears to be in its infancy. * It would kind of seem like mod_jk should be expanded to deal with WebSockets... * In any case, there would still be questions as to how this interacts with mod_jk within the same web app. 2. Any other browser considerations beyond requiring IE 10+? Are relatively recent Chrome, Firefox, and Safari WebSocket ready? http://en.wikipedia.org/wiki/WebSocket#Browser_support 3. How well do WebSockets play with existing network infrastructure? * IP load balancers * HTTP(S) forward and reverse proxy servers * Timeouts (idle, response, etc...) In general, if WebSockets don't just get along with existing network infrastructure in this regard but rather place requirements and restrictions upon it to function properly, then it will be a while before those of us who need to deploy a single solution into many disparate environments can leverage WebSockets in any substantive fashion. The way I understand websockets is : - it starts with a normal HTTP request from client to server. In that HTTP request, there is a header requesting an upgrade of the (theoretically one-off fire-and-forget) HTTP connection, to a websocket connection - if the server supports it, it does set aside the existing TCP connection (client-server), to be from now managed as a permanent client-server connection, and it lets the client know about this. From then on, the client and server have a permanent TCP connection, on which they can exchange websocket messages back and forth, until they agree that they are done, and drop the connection. To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. If there is a front-end between the client and the server (which actually runs the application that converses with the client over the websocket), then at the level of this front-end that connection must be like some kind of tunnel, which merely passes packets back and forth between the client and the back-end websocket-enabled application. That's a bit what the Apache httpd mod_proxy_(websocket) (not sure of the name anymore) sounds like. I have seen Rainer involved in that mod_proxy_(websocket) discussion, and since Rainer is one of the mod_jk developers, I would think that there must be some link with mod_jk. Which would make some sense, because if a browser connects to Tomcat through Apache httpd and mod_jk, and then requests an upgrade to websockets, mod_jk must be able to at least know that what is going to pass further on that connection is not HTTP-like anymore. But that's about all I've been able to sniff and guess so far. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
Hi Andre, On Thu, Jul 4, 2013 at 12:17 PM, André Warnier a...@ice-sa.com wrote: I'll just add a little bit of info (and guesses) below. Jess Holle wrote: Unfortunately I don't have any information -- just related questions. 1. For someone currently using Apache httpd+mod_jk to load balance requests, what does one do about load balancing WebSockets requests between Tomcat instances? * As Andre alluded to, the only mention of websocket handling in Apache httpd really appears to be in its infancy. * It would kind of seem like mod_jk should be expanded to deal with WebSockets... * In any case, there would still be questions as to how this interacts with mod_jk within the same web app. 2. Any other browser considerations beyond requiring IE 10+? Are relatively recent Chrome, Firefox, and Safari WebSocket ready? http://en.wikipedia.org/wiki/**WebSocket#Browser_supporthttp://en.wikipedia.org/wiki/WebSocket#Browser_support 3. How well do WebSockets play with existing network infrastructure? * IP load balancers * HTTP(S) forward and reverse proxy servers * Timeouts (idle, response, etc...) In general, if WebSockets don't just get along with existing network infrastructure in this regard but rather place requirements and restrictions upon it to function properly, then it will be a while before those of us who need to deploy a single solution into many disparate environments can leverage WebSockets in any substantive fashion. The way I understand websockets is : - it starts with a normal HTTP request from client to server. In that HTTP request, there is a header requesting an upgrade of the (theoretically one-off fire-and-forget) HTTP connection, to a websocket connection - if the server supports it, it does set aside the existing TCP connection (client-server), to be from now managed as a permanent client-server connection, and it lets the client know about this. From then on, the client and server have a permanent TCP connection, on which they can exchange websocket messages back and forth, until they agree that they are done, and drop the connection. To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). AFAIK when using BIO socket this is the case. But when using NIO (and AJP?!) Tomcat uses different threads per data frame. For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. If there is a front-end between the client and the server (which actually runs the application that converses with the client over the websocket), then at the level of this front-end that connection must be like some kind of tunnel, which merely passes packets back and forth between the client and the back-end websocket-enabled application. That's a bit what the Apache httpd mod_proxy_(websocket) (not sure of the name anymore) sounds like. I have seen Rainer involved in that mod_proxy_(websocket) discussion, and since Rainer is one of the mod_jk developers, I would think that there must be some link with mod_jk. Which would make some sense, because if a browser connects to Tomcat through Apache httpd and mod_jk, and then requests an upgrade to websockets, mod_jk must be able to at least know that what is going to pass further on that connection is not HTTP-like anymore. But that's about all I've been able to sniff and guess so far. --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
On 04/07/2013 10:17, André Warnier wrote: To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best Note that JSR356 allows blocking writes. If the client or the server opt to send data using a blocking write then that will use a thread until the write completes. Load-balancers should cope perfectly happily with this. There is no upgrade or WebSocket support in AJP yet. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
Mark Thomas wrote: On 04/07/2013 10:17, André Warnier wrote: To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best data to process meaning an entire websocket message I suppose ? Note that JSR356 allows blocking writes. If the client or the server opt to send data using a blocking write then that will use a thread until the write completes. Load-balancers should cope perfectly happily with this. There is no upgrade or WebSocket support in AJP yet. Thanks for these precisions. Another question while we're at it : As I understand from the specs/docs, there are 2 kinds of messages : text or blob. And I found that there are 2 ways of reading that data, corresponding to these 2 types of messages. However, I do not find anywhere a function or method or call which would allow for example the server-side application to find out in advance if the data currently available for reading is one or the other type. Did I miss that somewhere, or do I misunderstand the specs/docs ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
On Thu, Jul 4, 2013 at 5:52 PM, André Warnier a...@ice-sa.com wrote: Mark Thomas wrote: On 04/07/2013 10:17, André Warnier wrote: To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best data to process meaning an entire websocket message I suppose ? Note that JSR356 allows blocking writes. If the client or the server opt to send data using a blocking write then that will use a thread until the write completes. Load-balancers should cope perfectly happily with this. There is no upgrade or WebSocket support in AJP yet. Thanks for these precisions. Another question while we're at it : As I understand from the specs/docs, there are 2 kinds of messages : text or blob. And I found that there are 2 ways of reading that data, corresponding to these 2 types of messages. However, I do not find anywhere a function or method or call which would allow for example the server-side application to find out in advance if the data currently available for reading is one or the other type. Did I miss that somewhere, or do I misunderstand the specs/docs ? The application is being notified. The container calls either onMessage(String/CharBuffer) or onMessage(byte[]/ByteBuffer) on the endpoint (or whatever is the exact API) --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
On 04/07/2013 15:52, André Warnier wrote: Mark Thomas wrote: On 04/07/2013 10:17, André Warnier wrote: To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best data to process meaning an entire websocket message I suppose ? No. Data means bytes on the wire. It doesn't matter if those bytes are an entire message (multiple frames), a single frame, part of a frame of even the last few bytes of one frame and the first few bytes of the next. Tomcat will read what is available, process it as far as possible given that data it has to hand (for example if the application indicates it will except it, partial data can be passed to the application if it is available) and then release the thread and wait for the next set of bytes to turn up. Another question while we're at it : As I understand from the specs/docs, there are 2 kinds of messages : text or blob. And I found that there are 2 ways of reading that data, corresponding to these 2 types of messages. However, I do not find anywhere a function or method or call which would allow for example the server-side application to find out in advance if the data currently available for reading is one or the other type. Did I miss that somewhere, or do I misunderstand the specs/docs ? Actually, there are three types exposed to applications: Text, Binary, Pong. The application only finds out what type the message is when the container calls the appropriate message handler. Note if an application doesn't have a handler for a particular message type then the message is ignored. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
Regarding browser support, a framework like Atmosphere handles pretty well having WebSockets when they are available and falling-back to another Comet implementation (such as long-polling or http-streaming) when they are not. Le 4 juil. 2013 17:12, Mark Thomas ma...@apache.org a écrit : On 04/07/2013 15:52, André Warnier wrote: Mark Thomas wrote: On 04/07/2013 10:17, André Warnier wrote: To me that means that at some point, there must be on the server side a process or thread which is dedicated to this websocket client for as long as it takes, and this process/thread in the meantime is no longer available to process other HTTP requests. (That's because the basic idea is that the websocket application on the server side can keep sending messages asynchronously to the client - and vice-versa - so I don't see how this can work with different threads/processes on the server; but I'm not that smart, so it may be that the implementation is smarter). For that same reason, it would seem that the very concept of load-balancing must be suspended once the websocket connection is established. The connection has to be kept open but you can use non-blocking IO to only allocate a thread to process data when there is data to process. The exact behaviour varies between Tomcat 7 and Tomcat 8. BIO 7 8 - 1 thread per connections, blocking IO, doesn't scale NIO / APR 7 - 1 thread per currently processed frame, non-blocking between frames, scales better NIO / APR 8 - threads only allocated where there is data to process, scales best data to process meaning an entire websocket message I suppose ? No. Data means bytes on the wire. It doesn't matter if those bytes are an entire message (multiple frames), a single frame, part of a frame of even the last few bytes of one frame and the first few bytes of the next. Tomcat will read what is available, process it as far as possible given that data it has to hand (for example if the application indicates it will except it, partial data can be passed to the application if it is available) and then release the thread and wait for the next set of bytes to turn up. Another question while we're at it : As I understand from the specs/docs, there are 2 kinds of messages : text or blob. And I found that there are 2 ways of reading that data, corresponding to these 2 types of messages. However, I do not find anywhere a function or method or call which would allow for example the server-side application to find out in advance if the data currently available for reading is one or the other type. Did I miss that somewhere, or do I misunderstand the specs/docs ? Actually, there are three types exposed to applications: Text, Binary, Pong. The application only finds out what type the message is when the container calls the appropriate message handler. Note if an application doesn't have a handler for a particular message type then the message is ignored. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil goupilpie...@gmail.comwrote: Regarding browser support, a framework like Atmosphere handles pretty well having WebSockets when they are available and falling-back to another Comet implementation (such as long-polling or http-streaming) when they are not. agreed, but I think the goal/desire, here, is to not use Atmosphere.
websockets questions
Hi. I am looking for general and not so general info about websockets. I have read the Wikipedia article, RFC 6455, the websocket API doc on MSDN, and pretty much all that I have been able to find on the WWW. But I am still not sure if I have a full picture. This is the context : we are currently developing an application in which a client (initially, a user with a browser) enters a search expression and submits it to the server, for the server application to execute against a number of information providers (say Google Scholar, Pubmed and Amazon). The application on the server then, connects in parallel to these information providers, submits the search to each, and starts collecting results (list of articles or books e.g.). These results trickle in from the various sources, at different rates. The client is impatient, so it would be of benefit to start showing results in the browser as soon as some are available (on the server), and keep updating his display after that with whatever arrives from each source, more or less as it arrives. Typically, such an update from the server would be from 20 to 50 references (title, authors, etc.), so basically text, probably sent to the browser in JSON format. One classic way for us to implement this, would be by doing some kind of regular polling from the browser side, to ask if there is any update available. This is technically easy via AJAX techniques, but it requires quite a bit of machinery on the server side (sessions, long-running processes to reconnect to etc.), and is not very efficient. We were thus thinking that this might be a good case for implementation through a websockets connection, even though the needs are not as real-time as a game or a chat-like application for instance. And of course for our team of young developers, it would be rather attractive to be using some real cutting-edge technology.. However, from all my current perusing, it does seem to me that websockets is still not really production-ready (I am not talking about the Tomcat implementation per se, but more generally). For example, I could find a discussion thread from back in March this year (http://www.gossamer-threads.com/lists/apache/dev/423880), in which it seems that an Apache httpd proxy module for websockets is just in its infancy at the moment. There is also the fact that native websockets capability in IE is only available since IE-10, and that solutions which allow this to work in lower IE versions are a bit iffy (relying on a diversion through Adobe's FlashPlayer e.g.). (Most of our customers are largish corporations, which are not going to update their browsers, nor open special ports in their firewalls, just to please us). So, in short - so to speak - does anyone have comments to contribute about this ? Thanks André - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: websockets questions
Unfortunately I don't have any information -- just related questions. 1. For someone currently using Apache httpd+mod_jk to load balance requests, what does one do about load balancing WebSockets requests between Tomcat instances? * As Andre alluded to, the only mention of websocket handling in Apache httpd really appears to be in its infancy. * It would kind of seem like mod_jk should be expanded to deal with WebSockets... * In any case, there would still be questions as to how this interacts with mod_jk within the same web app. 2. Any other browser considerations beyond requiring IE 10+? Are relatively recent Chrome, Firefox, and Safari WebSocket ready? 3. How well do WebSockets play with existing network infrastructure? * IP load balancers * HTTP(S) forward and reverse proxy servers * Timeouts (idle, response, etc...) In general, if WebSockets don't just get along with existing network infrastructure in this regard but rather place requirements and restrictions upon it to function properly, then it will be a while before those of us who need to deploy a single solution into many disparate environments can leverage WebSockets in any substantive fashion. -- Jess Holle
