PHP Socket Programming, done the Right Way | Hacker News Reader

PHP Socket Programming, done the Right Way

christophh.net

51 pointsyuri4111 comments

Why not use a class? http://pear.php.net/package/Net_Socket

Or at least use namespaces. There is no reason to stick with the native PHP wrappers. It's common knowledge that PHP function names are illogical because of backward compatibility. So why not use a wrapper?

I think it's sad that even after PHP got all these features so that it resembles a proper programming languages, people aren't even using them! Makes me wonder if it was a good decision to force people to use classes in Java...

You seem to be under the assumption that classes are always categorically better than a procedural API. I think you're mistaken. Classes aren't always a good abstraction.

Classes being a good abstraction:

    $user = new User('John', 'Doe');
    $user->authenticate($token);

Classes being a bad abstraction:

    $two = Math::add(1, 1);
    // or worse:
    $math = new Math;
    $three = $math->sqrt(9);

In that latter case, you'd be much better served using a functional or procedural API, even if it's namespaced:

    (+ 1 1) ; two
    (math/sqrt 9) ; three

If you're going to argue that `stream_socket_` is doing it wrong, I'd like to hear why it'd be better as a OO API.

1.plus(1) looks quite sensible to me (every vector/matrix library I've seen has had a v.plus(v) or m.times(m) that returned a copy), though obviously sugar improves it. Sugar is irrelevant to OO vs procedural though.

OO is a good way to think about sockets because sockets are state machines. There's nothing wrong with passing around a socket called "this" to every procedure, but if you're doing that then you're just doing OO clumsily (i.e. without the benefit of being able to transparently substitute an SSL socket at a later point in time).

I think this is a good place to enter the "Right tool for the job" argument. The right tool not being PHP.

Code here looks good on first look tho.

Could you explain why PHP is not the right tool?

I've written plenty of sockets based PHP programs that run reliably and were easy and efficient to create. I didn't come across any problems that weren't easily surmountable.

If you're going to propose an negative argument, it would be helpful to at least outline the basis on which you are making it.

Let me preface by linking to a project of mine that is very much in the "things PHP is not great at" category - https://github.com/shaneharter/PHP-Daemon

Which is entirely why I have a disclaimer up top: "Note: For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this."

But there are enough reasons to use PHP (and enough people doing it) that good libraries like this socket library (and the Daemon library I linked above) are a really valuable contribution to the PHP community.

Can you list a few of the "many reasons" you talk about in the disclaimer?

I have a question regarding socket programming in general.

Let's say I want to build some sort of notification service. This could be instant messages, presence indication, or notification of file changes ala dropbox.

Now let's say that most of my clients are behind firewalls, forcing me to tie up one of my ports for each client as I do long polling or something else to keep the connection through their NAT open.

How do you keep from running out of ports? I only have 65K ports, right? How do some of these companies that have millions of open connections do it?

A connection is uniquely identified by (IP #1, Port #1) and (IP #2, Port #2).

You can have 65535 connections (in theory) from a single client to your port 80. And another 65535 from a different client to port 80 on the same server.

If you're serving a bunch of different clients it's not a problem.

How are there no comments? This is the most hilarious blog post title I've seen in ages!

Yeah, it sounds weird. But the code doesn't look as awful as i first expected. Which maybe silences a few of those comments (and this hasn't many votes).

Reply on news.ycombinator.com