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

Hot code ! #1

Open
osevan opened this issue Jan 4, 2024 · 1 comment
Open

Hot code ! #1

osevan opened this issue Jan 4, 2024 · 1 comment

Comments

@osevan
Copy link

osevan commented Jan 4, 2024

Great piece of software.

Thumbs up.

I have a question:
First question:
Can iip hijack go and rust compiled apps sockets or how i should run go and rust apps with it?

Second question :

Did you plan ever a solution to work with whole Linux networking system - especially ssh - and without disturbing current apps on nicks?

Thanks and

Best regards

@yasukata
Copy link
Owner

Thank you very much for your kind words.

Can iip hijack go and rust compiled apps sockets or how i should run go and rust apps with it?

The plan, currently I have, is to integrate the implementation of this repository through system call hook mechanisms such as https://github.com/yasukata/zpoline .

System call hook mechanisms can redirect the socket-relevant system calls invoked by a compiled application program to arbitrary code; I think we can use this mechanism to transparently apply our TCP/IP stack implementation to an existing application.

Did you plan ever a solution to work with whole Linux networking system - especially ssh - and without disturbing current apps on nicks?

I thought your question was "Can we co-locate this TCP/IP stack implementation with the whole Linux networking system (including ssh) on the same OS environment?" (please correct me if my understanding is wrong)

Even though the implementation in this repository assumes to fully occupy a NIC interface, I think that virtualized NIC interfaces allow us to co-locate it with the Linux networking system.

For instance, the SR-IOV feature of a physical NIC can create virtualized NICs (virtual functions), and it allows us to dedicate a virtual NIC (virtualized by SR-IOV) to the TCP/IP stack implementation of this repository while preserving the primary (non-virtualized) NIC interface for the default Linux networking system.

If a physical NIC does not support SR-IOV, we can still use a software-based virtual NIC, and we could find a study about the concept to co-locate multiple TCP/IP stacks using software-based virtual NIC interfaces in this paper https://dl.acm.org/doi/10.1145/2602204.2602212 .

On the other hand, one restriction of the approach based on virtual NICs would be that we cannot use the same IP address for the Linux networking system and the TCP/IP stack of this repository; I will explore another solution when needed.

Thank you very much for your interest.

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

No branches or pull requests

2 participants