4:52 p.m.
Was screwing around with a web socket implementation and thought, why
don't we use HTTP Upgrade as the basis for all of our proprietary
protocols? That way we can consolidate and remove a bunch of different
ports we expose and have a standard way to initiate each of our pet
protocols.
That would of course require our Web container to actually allow and be
optimized for this, but that's a different conversation.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:09 p.m.
Interesting that you brought this up Bill. We just had an e-mail thread around "port
reduction round 2" for the AS. For OpenShift, all the ports we use is problematic.
So, while we have made some good progress, we really need to take a bigger leap forward.
We should pursue this as part of AS 7.2 and above.
Andy
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org>
Sent: Friday, May 18, 2012 8:52:21 AM
Subject: [jboss-as7-dev] Consolidating ports under 80/443
Was screwing around with a web socket implementation and thought, why
don't we use HTTP Upgrade as the basis for all of our proprietary
protocols? That way we can consolidate and remove a bunch of
different
ports we expose and have a standard way to initiate each of our pet
protocols.
That would of course require our Web container to actually allow and
be
optimized for this, but that's a different conversation.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:25 p.m.
On Fri, 2012-05-18 at 10:52 -0400, Bill Burke wrote:
Was screwing around with a web socket implementation and thought, why
don't we use HTTP Upgrade as the basis for all of our proprietary
protocols? That way we can consolidate and remove a bunch of different
ports we expose and have a standard way to initiate each of our pet
protocols.
That would of course require our Web container to actually allow and be
optimized for this, but that's a different conversation.
The current WebSockets effort is here:
https://github.com/mikebrock/jboss-websockets
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
5:36 p.m.
On 5/18/12 11:25 AM, Remy Maucherat wrote:
On Fri, 2012-05-18 at 10:52 -0400, Bill Burke wrote:
> Was screwing around with a web socket implementation and thought, why
> don't we use HTTP Upgrade as the basis for all of our proprietary
> protocols? That way we can consolidate and remove a bunch of different
> ports we expose and have a standard way to initiate each of our pet
> protocols.
>
> That would of course require our Web container to actually allow and be
> optimized for this, but that's a different conversation.
The current WebSockets effort is here:
https://github.com/mikebrock/jboss-websockets
I'm not talking about websockets. There's a bunch of subsystems that
have their own proprietary protocols i.e. HornetQ has their superfast
protocol as well as STOMP, neither of which use HTTP or WebSockets.
THey could use HTTP Upgrade to connect, then just take over the socket
to do with whatever they wanted.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:35 p.m.
On Fri, 2012-05-18 at 11:36 -0400, Bill Burke wrote:
I'm not talking about websockets. There's a bunch of
subsystems that
have their own proprietary protocols i.e. HornetQ has their superfast
protocol as well as STOMP, neither of which use HTTP or WebSockets.
THey could use HTTP Upgrade to connect, then just take over the socket
to do with whatever they wanted.
WebSockets does an upgrade, so ...
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
7 p.m.
On 5/18/12 12:35 PM, Remy Maucherat wrote:
On Fri, 2012-05-18 at 11:36 -0400, Bill Burke wrote:
> I'm not talking about websockets. There's a bunch of subsystems that
> have their own proprietary protocols i.e. HornetQ has their superfast
> protocol as well as STOMP, neither of which use HTTP or WebSockets.
> THey could use HTTP Upgrade to connect, then just take over the socket
> to do with whatever they wanted.
WebSockets does an upgrade, so ...
Sure, but would require all these apps to run under a servlet container.
Most of them (all) don't want that dependency. Most of them (all)
don't want to have to use a native library (APR) to do non-blocking io.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:24 p.m.
How does control of processing the socket transfer from web tier to the associated service
executor/thread pool? Won't there need to be some kind of integration with the upgrade
processing?
----- Original Message -----
From: "Remy Maucherat" <rmaucher(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Friday, May 18, 2012 9:35:35 AM
Subject: Re: [jboss-as7-dev] Consolidating ports under 80/443
On Fri, 2012-05-18 at 11:36 -0400, Bill Burke wrote:
I'm not talking about websockets. There's a bunch of
subsystems that
have their own proprietary protocols i.e. HornetQ has their superfast
protocol as well as STOMP, neither of which use HTTP or WebSockets.
THey could use HTTP Upgrade to connect, then just take over the socket
to do with whatever they wanted.
WebSockets does an upgrade, so ...
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
1:24 a.m.
Web sockets are as good as anything else, as long as our implementation is solid. I
intend to investigate a websocket-based Remoting back end. The only question would be:
should protocols run on Remoting or directly over web sockets, or both? I think the
answer will depend on what kind of security and performance requirements each protocol
has.
--
- DML
On May 18, 2012, at 12:24 PM, Scott Stark <sstark(a)redhat.com> wrote:
How does control of processing the socket transfer from web tier to
the associated service executor/thread pool? Won't there need to be some kind of
integration with the upgrade processing?
----- Original Message -----
From: "Remy Maucherat" <rmaucher(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Friday, May 18, 2012 9:35:35 AM
Subject: Re: [jboss-as7-dev] Consolidating ports under 80/443
On Fri, 2012-05-18 at 11:36 -0400, Bill Burke wrote:
> I'm not talking about websockets. There's a bunch of subsystems that
> have their own proprietary protocols i.e. HornetQ has their superfast
> protocol as well as STOMP, neither of which use HTTP or WebSockets.
> THey could use HTTP Upgrade to connect, then just take over the socket
> to do with whatever they wanted.
WebSockets does an upgrade, so ...
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:07 p.m.
I think whether web sockets is used is orthogonal to what I'm
suggesting. I'm suggesting using Http Upgrade to negotiate any
protocol, of which websockets is just one. We will slow down connection
setup for our proprietary protocols, but gain port consolidation and
have a common way of plugging in new protocols. Also, a side effect
might be that everybody is using a common socket and threading layer.
On 5/18/12 7:24 PM, David Lloyd wrote:
Web sockets are as good as anything else, as long as our
implementation is solid. I intend to investigate a websocket-based Remoting back end. The
only question would be: should protocols run on Remoting or directly over web sockets, or
both? I think the answer will depend on what kind of security and performance
requirements each protocol has.
--
- DML
On May 18, 2012, at 12:24 PM, Scott Stark<sstark(a)redhat.com> wrote:
> How does control of processing the socket transfer from web tier to the associated
service executor/thread pool? Won't there need to be some kind of integration with the
upgrade processing?
>
> ----- Original Message -----
> From: "Remy Maucherat"<rmaucher(a)redhat.com>
> To: jboss-as7-dev(a)lists.jboss.org
> Sent: Friday, May 18, 2012 9:35:35 AM
> Subject: Re: [jboss-as7-dev] Consolidating ports under 80/443
>
> On Fri, 2012-05-18 at 11:36 -0400, Bill Burke wrote:
>> I'm not talking about websockets. There's a bunch of subsystems that
>> have their own proprietary protocols i.e. HornetQ has their superfast
>> protocol as well as STOMP, neither of which use HTTP or WebSockets.
>> THey could use HTTP Upgrade to connect, then just take over the socket
>> to do with whatever they wanted.
>
> WebSockets does an upgrade, so ...
>
> --
> Remy Maucherat<rmaucher(a)redhat.com>
> Red Hat Inc
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:11 p.m.
On Fri, 2012-05-18 at 13:24 -0400, Scott Stark wrote:
How does control of processing the socket transfer from web tier to
the associated service executor/thread pool? Won't there need to be
some kind of integration with the upgrade processing?
The upgrade callback allows access to the socket streams (without any
HTTP encoding, obviously) and async IO, but the whole thing remains
managed in the Servlet container. Servlet 3.1 will (likely) have a
similar upgrade callback with added async IO API.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
4382
days inactive
4383
days old
9 comments
5 participants
participants (5)
-
Andrig Miller -
Bill Burke -
David Lloyd -
Remy Maucherat -
Scott Stark