Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vnet: NewNet() should return an error #34

Closed
enobufs opened this issue Aug 22, 2019 · 0 comments · Fixed by #204
Closed

vnet: NewNet() should return an error #34

enobufs opened this issue Aug 22, 2019 · 0 comments · Fixed by #204
Milestone

Comments

@enobufs
Copy link
Member

enobufs commented Aug 22, 2019

There may be a case where a configuration error is detected by NewNew(), but it currently does not return an error. (this was found during the review for #33)

stv0g added a commit to stv0g/pion-transport that referenced this issue Sep 1, 2022
…' and 'vnet.Net'

This PR closes pion#34 and clearly separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change allows users to provide their own
'net.Net' implementation for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Sep 10, 2022
With initial implementations by 'net.StdNet' and 'vnet.Net'.
This PR closes pion#34 and clearly separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change allows users to provide their own
'net.Net' implementation for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Oct 9, 2022
With initial implementations by 'net.StdNet' and 'vnet.Net'.
This PR closes pion#34 and clearly separates the virtual network
'vnet.Net' from the code which is using in production.
Furthermore this change allows users to provide their
own 'net.Net' implementation for reasons like
the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Oct 9, 2022
With initial implementations by 'net.StdNet' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Oct 9, 2022
With initial implementations by 'net.StdNet' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
@enobufs enobufs added this to the V2 milestone Oct 29, 2022
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 13, 2022
With initial implementations by 'net.StdNet' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 15, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 15, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 15, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 15, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 16, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit to stv0g/pion-transport that referenced this issue Nov 19, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes pion#34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in pion#34.
stv0g added a commit that referenced this issue Nov 19, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes #34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in #34.
Sean-Der pushed a commit that referenced this issue Nov 30, 2022
With initial implementations by 'stdnet.Net' and
'vnet.Net'. This PR closes #34 and clearly
separates the virtual network 'vnet.Net' from the code
which is using in production. Furthermore this change
allows users to provide their own 'net.Net' implementation
for reasons like the one described in #34.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant