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

Feature request: Provide an API to get file descriptor of the Socket connection #481

Open
jliwork opened this issue Feb 12, 2024 · 2 comments

Comments

@jliwork
Copy link

jliwork commented Feb 12, 2024

I have a specific use case. I’m using pekko server to handle REST APIs calls. I need to get the file descriptor associated with socket connection then pass it to some legacy C program.

I'd like to request an API to get the file descriptor associated with socket connection for GET/POST REST APIs calls.

@pjfanning pjfanning transferred this issue from apache/pekko Feb 12, 2024
@pjfanning
Copy link
Contributor

I don't think it is a good idea for us to expose the internals of server sockets as file descriptors. Maybe someone else will have another view.

You might want to consider using another server tool that works at a lower level. You could take the requests on this other server and still use Pekko streams (or actors) if you want to continue to use Pekko for processing the requests.

@raboof
Copy link
Member

raboof commented Feb 13, 2024

I also suspect you might be better off with a lower-level API, but I'm pretty curious about your more exact use case :)

'Simply' passing the server socket to some other application will likely not work, as the connection is 'managed' by Pekko HTTP: for HTTP/1 it might do pipelining or wrap the connection in HTTPS, for HTTP/2 it might even do multiplexing - if the C program would read or write from that filesystem that would all break.

I guess perhaps you could stream the entity data to/from the application though - is that what you'd want?

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

3 participants