On 04/12/13 13:01, Gerard Davison wrote:
>
> On 4 Dec 2013, at 11:45, Pavel Bucek <pavel.bucek_at_oracle.com
> <mailto:pavel.bucek_at_oracle.com>> wrote:
>
>> Hi Gerard,
>>
>> sure, makes sense. (Although we could not use JDK 8 features yet...
>> ehm) :-)
>
> Well sure; but if you design the feature with a single method
> interface then it will work nicely with Lambdas in the future. :-)
>
>>
>> Feel free to file new RFE agains Tyrus. The other option might be
>> doing some tiny internal cache and then user should be able to have
>> similar advantage with possibility to use lambda expressions on
>> result of Session.getOpenSessions().. maybe I like this a little bit
>> more than adding broadcast method.
>
>
> I did think about this; but it would make it much harder to perform
> the same filter across a Cluster as per TYRUS-278
> <https://java.net/jira/browse/TYRUS-278>
Good point.. having broadcast method would be also more convenient to
the users which are looking for this scenario - getOpenSession() path is
not as straightforward..
>
>>
>> Anyway, even this might be resolved as part of solution of RFE you
>> are going to file, so please do it.
>
> Okay I will put something together this afternoon, once I have figured
> if and how Lamda serialise.
>
>>
>> Thanks!
>> Pavel
>>
>> ps.: did you have any interesting questions or feedback related to
>> WebSocket/Tyrus?
>
>
> The main question I got was just how many connections Tyrus would
> support on WLS, I fudged and suggested thousands in theory. Would
> would be the official line? Isn’t the maximum limit for on IPv4
> address something like (65535-1024 / 2) as you need two ports for each
> websocket?
I don't think there will be something like "official line". Anyway,
"thousands" is good answer :) The real number should be similar to max
number standard servlet request which can be handled "simultaneously",
but it will always depend on the endpoint implementation and system
resources.
BTW, single websocket connection does *not* require two TCP ports. It is
standard TCP/IP connection, same as for HTTP request. The only
difference is that the connection used for websocket upgrade cannot be
reused and will be always closed after websocket communication is over.
All connections are connecting to port 80 / 8080 / 7002 / wherever is
your appserver listening and that's it. Port related limit would be "64k
per client per server", which is very unlikely to affect regular
clients. So on the server side, the limit you'd hit would be most likely
number of opened file descriptors (considering there is enough memory etc..)
Pavel
>
> Gerard
>
>
>
>>
>> On 04/12/13 11:40, Gerard Davison wrote:
>>> So I was doing a presentation on WebSockets yesterday and it
>>> occurred to me that the “broadcast” method should really be extended
>>> so allow some kind of filtering on which connections the events is
>>> sent to, for example
>>>
>>> peer.broadcast(s ->
>>> s.getUserProperties().contains(“NAME”)).message(message);
>>> or
>>> peer.broadcast(message, s -> s.getUserProperties().contains(“NAME”));
>>>
>>> Does this seem reasonable for a range of use cases, if so I will
>>> raise a ER.
>>>
>>> Gerard
>>>
>>>
>>>
>>
>