Stream Control Transmission Protocol

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Stream Control Transmission Protocol

Ben Coman
Going through old issues, I see one [1] regarding adding SCTP [2]
support.  I've not heard of this protocol before. What are its
benefits and use case for Pharo/Squeak ?

Regarding our resource constraints, modularisation goal and ongoing
support, what is our strategy for this?
1. Integrate for Pharo 5?
2. Integrate into VM as plugin and have as external Configuration for
image?  (btw, remind me if a Configuration can also add a VM plugin?)
3. Continue to leave it for later.
4. Decline to use it.

Holger, What application are you using this for, and how are you
managing to work with this at the moment?

[1] https://pharo.fogbugz.com/default.asp?7346
[2] https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Stream Control Transmission Protocol

Holger Freyther

> On 05 Aug 2015, at 19:59, Ben Coman <[hidden email]> wrote:

Hi,


> Going through old issues, I see one [1] regarding adding SCTP [2]
> support.  I've not heard of this protocol before. What are its
> benefits and use case for Pharo/Squeak?

SCTP was designed by the telecommunication community to migrate
from systems using MTPL2/MTPL3. I am not going into the benefits
of SCTP itself but this protocol is the base for “SIGTRAN” and also
for backend systems in LTE networks. It was considered for things like
WebRTC as well.


> Regarding our resource constraints, modularisation goal and ongoing
> support, what is our strategy for this?

> 1. Integrate for Pharo 5?

no


> 2. Integrate into VM as plugin and have as external Configuration for
> image?  (btw, remind me if a Configuration can also add a VM plugin?)

no


> 3. Continue to leave it for later.

I am not sure. I think there should be two separate items:

* The SocketPlugin should know the SCTP network type and operations
like socket(2)/connect(2)/bind(2) should work. The beauty of the BSD
socket design is that the VM only needs to know how to deal with a
filedescriptor.

* There should be an additional plugin to bind the advanced sctp primitives.
This could work on OSX, FreeBSD and Linux.



> 4. Decline to use it.

Then I have to find different kind of work. :)


> Holger, What application are you using this for, and how are you
> managing to work with this at the moment?

I am using a piece of C application that handles SCTP/SIGTRAN and
provides a TCP/IP relay for Pharo.



Reply | Threaded
Open this post in threaded view
|

Re: Stream Control Transmission Protocol

Ben Coman
On Thu, Aug 6, 2015 at 2:12 AM, Holger Freyther <[hidden email]> wrote:

>
>> On 05 Aug 2015, at 19:59, Ben Coman <[hidden email]> wrote:
>
> Hi,
>
>
>> Going through old issues, I see one [1] regarding adding SCTP [2]
>> support.  I've not heard of this protocol before. What are its
>> benefits and use case for Pharo/Squeak?
>
> SCTP was designed by the telecommunication community to migrate
> from systems using MTPL2/MTPL3. I am not going into the benefits
> of SCTP itself but this protocol is the base for “SIGTRAN” and also
> for backend systems in LTE networks. It was considered for things like
> WebRTC as well.
>
>
>> Regarding our resource constraints, modularisation goal and ongoing
>> support, what is our strategy for this?
>
>> 1. Integrate for Pharo 5?
>
> no
>
>
>> 2. Integrate into VM as plugin and have as external Configuration for
>> image?  (btw, remind me if a Configuration can also add a VM plugin?)
>
> no
>
>
>> 3. Continue to leave it for later?
>
> I am not sure. I think there should be two separate items:
>
> * The SocketPlugin should know the SCTP network type and operations
> like socket(2)/connect(2)/bind(2) should work. The beauty of the BSD
> socket design is that the VM only needs to know how to deal with a
> filedescriptor.
>
> * There should be an additional plugin to bind the advanced sctp primitives.
> This could work on OSX, FreeBSD and Linux.
>

So it seems you only need VM changes integrated. How would you feel
about working directly with the vm-dev community to do this?  A ticket
in the Pharo bugtracker is implicitly waiting for someone else to pick
it up and push it, but Pharo has only a few busy people to work on the
VM, thus your ticket there has languished >2yrs.  There are more
non-Pharo vm-devs (who don't follow the Pharo bug tracker), so going
direct you might have a broader chance of getting it reviewed and
integrated.  This might not have been so practical when you first
logged your ticket since at that time the Pharo-VM had diverged from
the mainline-Cog-VM but its now realigned to get all the Spur
goodness, so Pharo would inherit your changes in due course.

Full disclosure: I'm trying to close old tickets to reduce our
software inventory [1] - but I hopefully this is a good path for you
also.
[1] http://www.joelonsoftware.com/items/2012/07/09.html

cheers -ben


>
>> 4. Decline to use it?
>
> Then I have to find different kind of work. :)
>
>
>> Holger, What application are you using this for, and how are you
>> managing to work with this at the moment?
>
> I am using a piece of C application that handles SCTP/SIGTRAN and
> provides a TCP/IP relay for Pharo.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Stream Control Transmission Protocol

stepharo

> So it seems you only need VM changes integrated. How would you feel
> about working directly with the vm-dev community to do this?  A ticket
> in the Pharo bugtracker is implicitly waiting for someone else to pick
> it up and push it, but Pharo has only a few busy people to work on the
> VM, thus your ticket there has languished >2yrs.  There are more
> non-Pharo vm-devs (who don't follow the Pharo bug tracker), so going
> direct you might have a broader chance of getting it reviewed and
> integrated.  This might not have been so practical when you first
> logged your ticket since at that time the Pharo-VM had diverged from
> the mainline-Cog-VM but its now realigned to get all the Spur
> goodness, so Pharo would inherit your changes in due course.
>
> Full disclosure: I'm trying to close old tickets to reduce our
> software inventory [1] - but I hopefully this is a good path for you
> also.
> [1] http://www.joelonsoftware.com/items/2012/07/09.html
>
> cheers -ben

Thanks ben. You are so right :)