New Transport Interface

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

New Transport Interface

Răzvan Crainea-2
Hello, all!

Whilde developing the design of the new WebSockets protocol, we observed
that we can't easily use the existing TCP core, and we have to duplicate
a lot of code to make it work fine. Since this is not a very good idea,
we started designing how this could be done nicer and more efficient.
That's how we ended up designing a new Transport Interface[1], that
provides a clear separation between IP layer transport protocols (such
as TCP and UDP) and higher level protocols (such as WebSocket, TLS,
etc.). This interface will facilitate the development of new Transport
Protocols, while reusing the existing TCP and UDP implementation.
The new design can be found here[1]. Feel free to give us any feedback
or thoughts about this.

[1] http://www.opensips.org/Development/TransportInterface

Best regards,

--
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com


_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Ovidiu Sas
Nice!  It would be good to add the API documentation.

-ovidiu

On Fri, Dec 19, 2014 at 7:46 AM, Răzvan Crainea <[hidden email]> wrote:

> Hello, all!
>
> Whilde developing the design of the new WebSockets protocol, we observed
> that we can't easily use the existing TCP core, and we have to duplicate a
> lot of code to make it work fine. Since this is not a very good idea, we
> started designing how this could be done nicer and more efficient. That's
> how we ended up designing a new Transport Interface[1], that provides a
> clear separation between IP layer transport protocols (such as TCP and UDP)
> and higher level protocols (such as WebSocket, TLS, etc.). This interface
> will facilitate the development of new Transport Protocols, while reusing
> the existing TCP and UDP implementation.
> The new design can be found here[1]. Feel free to give us any feedback or
> thoughts about this.
>
> [1] http://www.opensips.org/Development/TransportInterface
>
> Best regards,
>
> --
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
>
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Bogdan-Andrei Iancu-2
yes, that is the next step, to work out those interfaces. Then we can
start re-arranging and re-building the code.

Regards,
Bogdan

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 19.12.2014 17:36, Ovidiu Sas wrote:

> Nice!  It would be good to add the API documentation.
>
> -ovidiu
>
> On Fri, Dec 19, 2014 at 7:46 AM, Răzvan Crainea <[hidden email]> wrote:
>> Hello, all!
>>
>> Whilde developing the design of the new WebSockets protocol, we observed
>> that we can't easily use the existing TCP core, and we have to duplicate a
>> lot of code to make it work fine. Since this is not a very good idea, we
>> started designing how this could be done nicer and more efficient. That's
>> how we ended up designing a new Transport Interface[1], that provides a
>> clear separation between IP layer transport protocols (such as TCP and UDP)
>> and higher level protocols (such as WebSocket, TLS, etc.). This interface
>> will facilitate the development of new Transport Protocols, while reusing
>> the existing TCP and UDP implementation.
>> The new design can be found here[1]. Feel free to give us any feedback or
>> thoughts about this.
>>
>> [1] http://www.opensips.org/Development/TransportInterface
>>
>> Best regards,
>>
>> --
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>


_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Răzvan Crainea-2
Hi, All!

You can find here[2] the APIs that are going to be deeveloped for the
Transport Interface.
Please take a look and let us know what you think. Any feedback is welcome!

[1] http://www.opensips.org/Development/TransportInterfaceAPI

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 12/19/2014 06:05 PM, Bogdan-Andrei Iancu wrote:

> yes, that is the next step, to work out those interfaces. Then we can
> start re-arranging and re-building the code.
>
> Regards,
> Bogdan
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 19.12.2014 17:36, Ovidiu Sas wrote:
>> Nice!  It would be good to add the API documentation.
>>
>> -ovidiu
>>
>> On Fri, Dec 19, 2014 at 7:46 AM, Răzvan Crainea <[hidden email]>
>> wrote:
>>> Hello, all!
>>>
>>> Whilde developing the design of the new WebSockets protocol, we
>>> observed
>>> that we can't easily use the existing TCP core, and we have to
>>> duplicate a
>>> lot of code to make it work fine. Since this is not a very good
>>> idea, we
>>> started designing how this could be done nicer and more efficient.
>>> That's
>>> how we ended up designing a new Transport Interface[1], that provides a
>>> clear separation between IP layer transport protocols (such as TCP
>>> and UDP)
>>> and higher level protocols (such as WebSocket, TLS, etc.). This
>>> interface
>>> will facilitate the development of new Transport Protocols, while
>>> reusing
>>> the existing TCP and UDP implementation.
>>> The new design can be found here[1]. Feel free to give us any
>>> feedback or
>>> thoughts about this.
>>>
>>> [1] http://www.opensips.org/Development/TransportInterface
>>>
>>> Best regards,
>>>
>>> --
>>> Răzvan Crainea
>>> OpenSIPS Solutions
>>> www.opensips-solutions.com
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>
>
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Saúl Ibarra Corretgé
Hi Razvan (and all!),

On 12 Jan 2015, at 14:52, Răzvan Crainea <[hidden email]> wrote:

> Hi, All!
>
> You can find here[2] the APIs that are going to be deeveloped for the Transport Interface.
> Please take a look and let us know what you think. Any feedback is welcome!
>
> [1] http://www.opensips.org/Development/TransportInterfaceAPI
>

Sorry for not having participated earlier. Hopefully I can do that more now!

I had a look at the API, and while the layer separation sounds good, I have some questions / concerns of different nature. Here is a brain-dump, in no particular order:

- If TLS is taken out of the core it would be best to rewrite it without looking at the current code. If we want to get OpenSIPS as an official Debian package, the TLS code needs to be a separate module, with a different license (GPL with the OpenSSL exception thing), but in order to relicense it all developers have to agree, doing it from scratch would avoid this.

- If TLS is a module now, has there been any thought on supporting implementations other than OpenSSL? gnuTLS and libreSSL come to mind.

- I see that the send / receive API is not designed with scatter / gather I/O in mind. It might be beneficial in the long run to support sending or receiving an array of buffers, and use readv / writev underneath.

- sockaddr_union is defined by OpenSIPS with no real purpose these days, since we can use sockaddr_storage for allocating space and sockaddr for passing around pointers.

- At what level are the TLS settings considered? Network or transport? Either way, all init functions get void, but where will the config be taken from, if it’s different per domain?

- The transport API has some inconsistencies in what parameters it takes: connect gets a sockaddr, but bind gets host and port.

- Where do DNS lookups happen? If the transport API only knows about IPs and ports then all functions should take sockaddr structures and the app would do the lookup.

- Any thoughts on using “connected” UDP sockets, so the kernel does the filtering for incoming traffic?


I hope this helps.


Cheers,

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Ovidiu Sas
In reply to this post by Răzvan Crainea-2
Small typo for "TCP network proto": seems that destroy_udp() is meant
to be destroy_tcp().

-ovidiu

On Mon, Jan 12, 2015 at 8:52 AM, Răzvan Crainea <[hidden email]> wrote:

> Hi, All!
>
> You can find here[2] the APIs that are going to be deeveloped for the
> Transport Interface.
> Please take a look and let us know what you think. Any feedback is welcome!
>
> [1] http://www.opensips.org/Development/TransportInterfaceAPI
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
>
> On 12/19/2014 06:05 PM, Bogdan-Andrei Iancu wrote:
>>
>> yes, that is the next step, to work out those interfaces. Then we can
>> start re-arranging and re-building the code.
>>
>> Regards,
>> Bogdan
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 19.12.2014 17:36, Ovidiu Sas wrote:
>>>
>>> Nice!  It would be good to add the API documentation.
>>>
>>> -ovidiu
>>>
>>> On Fri, Dec 19, 2014 at 7:46 AM, Răzvan Crainea <[hidden email]>
>>> wrote:
>>>>
>>>> Hello, all!
>>>>
>>>> Whilde developing the design of the new WebSockets protocol, we observed
>>>> that we can't easily use the existing TCP core, and we have to duplicate
>>>> a
>>>> lot of code to make it work fine. Since this is not a very good idea, we
>>>> started designing how this could be done nicer and more efficient.
>>>> That's
>>>> how we ended up designing a new Transport Interface[1], that provides a
>>>> clear separation between IP layer transport protocols (such as TCP and
>>>> UDP)
>>>> and higher level protocols (such as WebSocket, TLS, etc.). This
>>>> interface
>>>> will facilitate the development of new Transport Protocols, while
>>>> reusing
>>>> the existing TCP and UDP implementation.
>>>> The new design can be found here[1]. Feel free to give us any feedback
>>>> or
>>>> thoughts about this.
>>>>
>>>> [1] http://www.opensips.org/Development/TransportInterface
>>>>
>>>> Best regards,
>>>>
>>>> --
>>>> Răzvan Crainea
>>>> OpenSIPS Solutions
>>>> www.opensips-solutions.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



--
VoIP Embedded, Inc.
http://www.voipembedded.com

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Răzvan Crainea-2
In reply to this post by Saúl Ibarra Corretgé
Hi, Saul!

You have my answers inline.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 01/13/2015 01:12 PM, Saúl Ibarra Corretgé wrote:
> Hi Razvan (and all!),
> Sorry for not having participated earlier. Hopefully I can do that more now!
>
> I had a look at the API, and while the layer separation sounds good, I have some questions / concerns of different nature. Here is a brain-dump, in no particular order:
>
> - If TLS is taken out of the core it would be best to rewrite it without looking at the current code. If we want to get OpenSIPS as an official Debian package, the TLS code needs to be a separate module, with a different license (GPL with the OpenSSL exception thing), but in order to relicense it all developers have to agree, doing it from scratch would avoid this.
I'm not sure how rewriting the whole module will solve this. Even though
it's a different code, it will still have the OpenSSL exception so it
can't be part of a Debian package. However, this time we will be able to
add the OpenSIPS core in the Debian repo.
>
> - If TLS is a module now, has there been any thought on supporting implementations other than OpenSSL? gnuTLS and libreSSL come to mind.
Since the new interface will be very modular, having a different TLS
implementation will be very simple. All they have to do is to implement
the Transport Interface functions.
>
> - I see that the send / receive API is not designed with scatter / gather I/O in mind. It might be beneficial in the long run to support sending or receiving an array of buffers, and use readv / writev underneath.
This would be a nice feature, but the current code is not yet ready to
support this. But we should keep track of this for further releases.
>
> - sockaddr_union is defined by OpenSIPS with no real purpose these days, since we can use sockaddr_storage for allocating space and sockaddr for passing around pointers.
Currently sockaddr_union is not only used for storage, but is also
allows you to access the structure as sockaddr or sockaddr_in without
doing any explicit casts.
>
> - At what level are the TLS settings considered? Network or transport? Either way, all init functions get void, but where will the config be taken from, if it’s different per domain?
The TLS settings will be considered at the transport level. We could
implement the domain logic in the mod_init() function, that is not part
of the Transport Interface but of the general Modules Interface.
>
> - The transport API has some inconsistencies in what parameters it takes: connect gets a sockaddr, but bind gets host and port.
Well, this is not the final version of the API, and most likely during
development some of those signatures will change. What we have there is
a roughly design we think should be used to implement this interface.But
indeed, during development we'll pay attention to these inconsitencies
and try to avoid them.
>
> - Where do DNS lookups happen? If the transport API only knows about IPs and ports then all functions should take sockaddr structures and the app would do the lookup.
The DNS lookup is already done on a higher level, by the OpenSIPS Core.
At this level we have the IP and ports already resolved.
>
> - Any thoughts on using “connected” UDP sockets, so the kernel does the filtering for incoming traffic?
We haven't considered this and I am not sure how this would should work.
Currently OpenSIPS only has a single socket per UDP listening interface.
Using "connected" UDP sockets would require having multiple sockets,
each connected to an "authorized" client. Therefore we'd have to
implement a socket management logic in the UDP transport interface to
handle this. This will increase the complexity of the UDP communication
and most likely decrease it's performance.

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Răzvan Crainea-2
In reply to this post by Ovidiu Sas
Hi Ovidiu!

Fixed the typo, thanks!
As I said the the previous mail, this is not the final version of the
API, and most likely it will suffer a set of changes during the
implementation. But it stands as a starting point.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 01/13/2015 04:28 PM, Ovidiu Sas wrote:

> Small typo for "TCP network proto": seems that destroy_udp() is meant
> to be destroy_tcp().
>
> -ovidiu
>
> On Mon, Jan 12, 2015 at 8:52 AM, Răzvan Crainea <[hidden email]> wrote:
>> Hi, All!
>>
>> You can find here[2] the APIs that are going to be deeveloped for the
>> Transport Interface.
>> Please take a look and let us know what you think. Any feedback is welcome!
>>
>> [1] http://www.opensips.org/Development/TransportInterfaceAPI
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutions
>> www.opensips-solutions.com
>>
>> On 12/19/2014 06:05 PM, Bogdan-Andrei Iancu wrote:
>>> yes, that is the next step, to work out those interfaces. Then we can
>>> start re-arranging and re-building the code.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>> On 19.12.2014 17:36, Ovidiu Sas wrote:
>>>> Nice!  It would be good to add the API documentation.
>>>>
>>>> -ovidiu
>>>>
>>>> On Fri, Dec 19, 2014 at 7:46 AM, Răzvan Crainea <[hidden email]>
>>>> wrote:
>>>>> Hello, all!
>>>>>
>>>>> Whilde developing the design of the new WebSockets protocol, we observed
>>>>> that we can't easily use the existing TCP core, and we have to duplicate
>>>>> a
>>>>> lot of code to make it work fine. Since this is not a very good idea, we
>>>>> started designing how this could be done nicer and more efficient.
>>>>> That's
>>>>> how we ended up designing a new Transport Interface[1], that provides a
>>>>> clear separation between IP layer transport protocols (such as TCP and
>>>>> UDP)
>>>>> and higher level protocols (such as WebSocket, TLS, etc.). This
>>>>> interface
>>>>> will facilitate the development of new Transport Protocols, while
>>>>> reusing
>>>>> the existing TCP and UDP implementation.
>>>>> The new design can be found here[1]. Feel free to give us any feedback
>>>>> or
>>>>> thoughts about this.
>>>>>
>>>>> [1] http://www.opensips.org/Development/TransportInterface
>>>>>
>>>>> Best regards,
>>>>>
>>>>> --
>>>>> Răzvan Crainea
>>>>> OpenSIPS Solutions
>>>>> www.opensips-solutions.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>


_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Saúl Ibarra Corretgé
In reply to this post by Răzvan Crainea-2
Hi Razvan!

I understand it’s just the beginning, hence my comments, targeted at (hopefully) improving things :-)

>> - If TLS is taken out of the core it would be best to rewrite it without looking at the current code. If we want to get OpenSIPS as an official Debian package, the TLS code needs to be a separate module, with a different license (GPL with the OpenSSL exception thing), but in order to relicense it all developers have to agree, doing it from scratch would avoid this.
> I'm not sure how rewriting the whole module will solve this. Even though it's a different code, it will still have the OpenSSL exception so it can't be part of a Debian package. However, this time we will be able to add the OpenSIPS core in the Debian repo.

It would solve the problem. Having the exception if fine, but if TLS is in the core, OpenSIPS would need to be relicensed in its entirety, but having it as a module, the exception would only apply to that module.

>>
>> - If TLS is a module now, has there been any thought on supporting implementations other than OpenSSL? gnuTLS and libreSSL come to mind.
> Since the new interface will be very modular, having a different TLS implementation will be very simple. All they have to do is to implement the Transport Interface functions.
>>

Awesome!

>> - I see that the send / receive API is not designed with scatter / gather I/O in mind. It might be beneficial in the long run to support sending or receiving an array of buffers, and use readv / writev underneath.
> This would be a nice feature, but the current code is not yet ready to support this. But we should keep track of this for further releases.
>>

While the current code might not *use* it, I think allowing for it at the API level would be nice to have, it basically revolves around using the vectored functions if the number of buffers is > 1.

>> - sockaddr_union is defined by OpenSIPS with no real purpose these days, since we can use sockaddr_storage for allocating space and sockaddr for passing around pointers.
> Currently sockaddr_union is not only used for storage, but is also allows you to access the structure as sockaddr or sockaddr_in without doing any explicit casts.

So? Is casting to struct sockaddr* in a few places necessarily wrong?

>>
>> - At what level are the TLS settings considered? Network or transport? Either way, all init functions get void, but where will the config be taken from, if it’s different per domain?
> The TLS settings will be considered at the transport level. We could implement the domain logic in the mod_init() function, that is not part of the Transport Interface but of the general Modules Interface.
>>

Ok.

>> - The transport API has some inconsistencies in what parameters it takes: connect gets a sockaddr, but bind gets host and port.
> Well, this is not the final version of the API, and most likely during development some of those signatures will change. What we have there is a roughly design we think should be used to implement this interface.But indeed, during development we'll pay attention to these inconsitencies and try to avoid them.
>>
>> - Where do DNS lookups happen? If the transport API only knows about IPs and ports then all functions should take sockaddr structures and the app would do the lookup.
> The DNS lookup is already done on a higher level, by the OpenSIPS Core. At this level we have the IP and ports already resolved.
>>

Cool. In that case I suggest the transport API just gets sockaddr parameters and the conversion be done elsewhere. consistency++ :-)

>> - Any thoughts on using “connected” UDP sockets, so the kernel does the filtering for incoming traffic?
> We haven't considered this and I am not sure how this would should work. Currently OpenSIPS only has a single socket per UDP listening interface. Using "connected" UDP sockets would require having multiple sockets, each connected to an "authorized" client. Therefore we'd have to implement a socket management logic in the UDP transport interface to handle this. This will increase the complexity of the UDP communication and most likely decrease it's performance.
>

I didn’t think this all the way through, but the advantage would be that the kernel does the filtering. It’s not a big deal anyway, just checking if you folks gave the idea any thought.


Keep up the good work!

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New Transport Interface

Răzvan Crainea-2
On 01/14/2015 02:55 PM, Saúl Ibarra Corretgé wrote:
> Hi Razvan!
>
> I understand it’s just the beginning, hence my comments, targeted at (hopefully) improving things :-)
>
>>> - If TLS is taken out of the core it would be best to rewrite it without looking at the current code. If we want to get OpenSIPS as an official Debian package, the TLS code needs to be a separate module, with a different license (GPL with the OpenSSL exception thing), but in order to relicense it all developers have to agree, doing it from scratch would avoid this.
>> I'm not sure how rewriting the whole module will solve this. Even though it's a different code, it will still have the OpenSSL exception so it can't be part of a Debian package. However, this time we will be able to add the OpenSIPS core in the Debian repo.
> It would solve the problem. Having the exception if fine, but if TLS is in the core, OpenSIPS would need to be relicensed in its entirety, but having it as a module, the exception would only apply to that module.
Yes, the idea is to completely remove the TLS code from the core and
move everything in a module.
>
>>> - If TLS is a module now, has there been any thought on supporting implementations other than OpenSSL? gnuTLS and libreSSL come to mind.
>> Since the new interface will be very modular, having a different TLS implementation will be very simple. All they have to do is to implement the Transport Interface functions.
> Awesome!
>
>>> - I see that the send / receive API is not designed with scatter / gather I/O in mind. It might be beneficial in the long run to support sending or receiving an array of buffers, and use readv / writev underneath.
>> This would be a nice feature, but the current code is not yet ready to support this. But we should keep track of this for further releases.
> While the current code might not *use* it, I think allowing for it at the API level would be nice to have, it basically revolves around using the vectored functions if the number of buffers is > 1.
Yes, I think this is doable.
>
>>> - sockaddr_union is defined by OpenSIPS with no real purpose these days, since we can use sockaddr_storage for allocating space and sockaddr for passing around pointers.
>> Currently sockaddr_union is not only used for storage, but is also allows you to access the structure as sockaddr or sockaddr_in without doing any explicit casts.
> So? Is casting to struct sockaddr* in a few places necessarily wrong?
No, it is not wrong at all. Actually, at machine code level, the two
aproaches are translated into the same thing. It's just that I find
sockaddr_union easier to use than explicit cast. It's just a typing
difference, sock.s vs (struct sockaddr *)&sock.

>
>>> - At what level are the TLS settings considered? Network or transport? Either way, all init functions get void, but where will the config be taken from, if it’s different per domain?
>> The TLS settings will be considered at the transport level. We could implement the domain logic in the mod_init() function, that is not part of the Transport Interface but of the general Modules Interface.
> Ok.
>
>>> - The transport API has some inconsistencies in what parameters it takes: connect gets a sockaddr, but bind gets host and port.
>> Well, this is not the final version of the API, and most likely during development some of those signatures will change. What we have there is a roughly design we think should be used to implement this interface.But indeed, during development we'll pay attention to these inconsitencies and try to avoid them.
>>> - Where do DNS lookups happen? If the transport API only knows about IPs and ports then all functions should take sockaddr structures and the app would do the lookup.
>> The DNS lookup is already done on a higher level, by the OpenSIPS Core. At this level we have the IP and ports already resolved.
> Cool. In that case I suggest the transport API just gets sockaddr parameters and the conversion be done elsewhere. consistency++ :-)
Not sure which functions you're talking about. Is it the connect() function?
>
>>> - Any thoughts on using “connected” UDP sockets, so the kernel does the filtering for incoming traffic?
>> We haven't considered this and I am not sure how this would should work. Currently OpenSIPS only has a single socket per UDP listening interface. Using "connected" UDP sockets would require having multiple sockets, each connected to an "authorized" client. Therefore we'd have to implement a socket management logic in the UDP transport interface to handle this. This will increase the complexity of the UDP communication and most likely decrease it's performance.
>>
> I didn’t think this all the way through, but the advantage would be that the kernel does the filtering. It’s not a big deal anyway, just checking if you folks gave the idea any thought.
>
I think the idea is interesting, we'll push it for further discussions.

Thanks for your input!

Best regards,
Răzvan

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel