I mentioned this a bit in the tech meeting but I'll recap here so can
kick it around.
At first pass, I'm just planning on having the WebSocket tell the WSE
"here's my frame. send it." Initially that'll be a blocking call (just
as it is now) because the important part is getting all that IO
centralized and simplifying the WS classes. Once that's done and work,
I'd like to look into a queue/worker thread set up where those frames
get queued up and a worker thread manages sending them.
Where that thread comes from and how it's managed will be subject to
some debate, I'm sure. We could borrow one of the http-worker-threads
already in the system. Or we could set up an ExecutorService with
either 1 worker thread or 1 thread per application. There are
performance concerns either way probably so we'll want to be careful
about it.
While I'm on the subject, we'll also want to consider how best to
prevent DOS attacks when someone decides to open a billion connections
against the server and then leaving them open. The WS spec suggests
that clients (i.e., browsers primarily) limit outbound WS connections to
2 per remote IP. Initially, that's probably not a bad limit on the
server, too. I'm not sure if we want to make that configurable or not
but I think we should definitely put *some* limit in.
On 6/30/10 12:24 PM, Oleksiy Stashok wrote:
> Hi Justin,
>
>> If you've been following the issues, you will have seen that I've
>> finally been able to address a number of long standing issues with
>> websockets on the trunk. Specifically today, i'm tackling
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=841. This one
>> has never sat well with and I'm going to clean that up. Here's what
>> I'm thinking. I'm going to remove all notion of IO from the
>> WebSocket on the server. (Client obviously still has to deal with
>> stuff). Already on the server, we have an object capturing the key
>> selection events and notifying the WebSocket object to read an
>> unframe data. I want to move this out so that all the reading from
>> the wire is done outside the WebSocket object. Once the data is
>> read, the DataFrame will be passed to the WebSocket to handle as it
>> wishes.
> Sounds good!
>
>
>> Going the other way, the WebSocket will build the DataFrame and
>> notify the WebSocketEngine that it's ready to send. The WSE will
>> have at least one thread to handle the actual writing of messages out
>> to the client. This will give us an NIO-oriented approach to sending
>> data while simultaneously simplifying any server side WebSocket
>> classes. It also makes testing these classes *really* simple as
>> there is no network layer that needs to be mocked away. It also
>> paves the way for dramatically simplifying the internal code as it
>> would potentially let us refactor the client and server sides to much
>> more common code. (The difference being the handling of network
>> traffic).
> Can you pls. explain, you're planning to do actual writing in a
> separate thread?
>
> WBR,
> Alexey.
>
>>
>> Hopefully this makes sense. If there are any objections, please
>> speak up as I'm trying this now to test its general feasibility. It
>> should work rather nicely and clean up the code quite a bit as well.
>> If there are no objections, and if this approach works, it should be
>> in svn in a day or two.
>>
>> Now's the time to speak up, though. :)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>