Jump to content

Creating unix domain socket to a file path


NotionCommotion

Recommended Posts

Thanks Jacques1,

 

I had done so, and thought that http://php.net/manual/en/function.stream-socket-server.php is the right direction.  They give examples of Internet Domain sockets (AF_INET) such as TCP and UDP, but not Unix domain sockets.  For unix sockets, I will try using unix:///tmp/pa.

 

Am I on the right path?  Any other words of wisdom?

 

Thanks

Link to comment
Share on other sites

unix is the scheme for Unix sockets, yes.

 

A fair warning: If you're going back to low-level sockets (for whatever reason), be prepared for extensive research and learning on your own. Understanding the PHP stream API is actually the trivial part. Then you need to implement and possibly even design a protocol to handle the communication, which isn't something you'll find in a step-by-step tutorial.

 

And as always, we can only comment on the information you've provided. Whether your design choices even make sense is impossible to tell without knowing the full context.

Link to comment
Share on other sites

I understand that I provided very little information and can not expect much comments.  I am in the discovery phase, and have very little information to give.

 

I am building a PHP client application which bidirectionally communicates to a remote server using ReactPHP.  This part is working.

 

Now, it needs to bidirectionally communicate to a C++ application residing on the same machine.  Messages from the PHP client app need to somehow be transmitted to the C++ app, and the C++ app needs to somehow transmit messages to the PHP app.

 

The C++ author recommends using Unix domain sockets along with JSON-RPC where the C++ app is a client and the PHP app is a server.

 

I do not have enough knowledge or expertise on this subject to question doing differently.  What information would be needed to agree with this recommend or recommend doing differently?

 

Thanks

Link to comment
Share on other sites

If the C++ application already has an implementation for JSON-RPC over Unix domain sockets, you don't really have a choice.

 

If both applications currently have no communication component at all, I would use a message-oriented mechanism (e. g. a message queue), so that you don't have to assemble the data from a byte stream.

Link to comment
Share on other sites

As I mentioned in a previous PM, I really think Node.js is a much better tool for what you're doing. (For as much I understand your project). PM me enough working details of what you're doing and I will see what I can do in Node. I know you are not at a place to learn a new "language" right now. It will give me a real example that will help my skills in Node and I will also be able to bumpstart you with learning Node if/when you ever get there.

Link to comment
Share on other sites

From what I have learned of it so far, it seems well suited for real time two way connections using web sockets, which from what I gather from @NotionCommotion's posts and PM's is what he is doing.

 

A node description I read that seems to fit. 

 

The main idea of Node.js: use non-blocking, event-driven I/O to remain lightweight and efficient in the face of data-intensive real-time applications that run across distributed devices.

 

Of course, I am just starting to learn it which is why a real project would be nice to work with.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.