Re: OCPTRAN as OCP transport

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

Hilarie,

	You mentioned that a new custom OCP transport is the best way
to proceed, but did not follow up on that suggestion. As of now, we
seem to have two existing transports to consider: BEEP and HTTP. Do
you still think a new, custom transport would be better? If yes, can
you elaborate? You can use my specific questions below to start with
(they split the problem into two semi-independent parts: new versus
old transport and reliable versus lossy transport).

	It would be great to have more information so that we can
summarize the advantages/disadvantages of all transports and make the
final selection.

Thank you,

Alex.


On Thu, 17 Apr 2003, Alex Rousskov wrote:

>
> On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote:
>
> > Personally, I think the best choice is a new transport named OCPTRAN
> > that can run over TCP for data that needs reliable service and can
> > also run over UDP or just IP if need be.
>
> If the group is convinced that designing a new transport is a good
> idea, one way to proceed is to take BEEP, remove its XML dependency
> (unless we choose to use XML for OCP messages) and remove mandatory
> responses. Doing just that will allow us to reuse a lot of existing
> documentation (and even code). Hilarie, could you please try to
> convince us that new transport is needed assuming no UDP support is
> required?
>
> Hmm... The above can be rephrased in a more direct way, I guess:
> Hilarie, what is wrong with BEEP, assuming no UDP support is required?
> Once we know what is wrong, we can see what it would take to fix it.
>
>
> If the group is further convinced that unreliable transport support is
> needed, I would suggest that we add lossy transport support to the
> above. Hilarie, could you please try to convince us that unreliable
> transport support is required? More specifically, what kind of
> application protocols cannot be adapted with OCP/TCP using a
> reasonable set of OCP transaction timeouts to accomodate slow callout
> servers or bad connectivity to them?
>
> Thank you,
>
> Alex.
>