Hacker Newsnew | past | comments | ask | show | jobs | submit | BuckToBid's commentslogin

I just had an submission hit the front page the other day where I explained how moving from PHP/Apache to C saved my bacon. I'm 26 and have not been out of school that long.

I would look for schools who start their students in C or even C++ right off the bat. I know some people who took intro to programming in Java and would never learn C now, not sure why.


Yes there are many penny auction sites out there. The whole reason to link it to facebook is so that you know its a real person you are bidding against. How do you know wavee has all real people bidding? You don't some of their users could just as easily be bots bidding items up automatically.


The thing is, Wavee is not an auction site. An auction site is one in which bids are free, and the winner pays what their bid says they pay. What Wavee had, and what you have built are, effectively, a method of taking money from people for the opportunity to pay money for something.

Don't get me wrong, it's an amazing racket; Wavee makes 75 cents for every bid coming in to increment the value by 1 cent. Saw a $150 iPad. That iPad has already earned Wavee's owners $11,250 without even being sold! And the use of Facebook to gain the trust of people is a good marketing tactic, but it doesn't skirt the fact that creating fake Facebook users with a bunch of friends is easy (get some pictures, feed some content in from any one of the millions of open twitter accounts, etc.), or that you have a real incentive to perpetrate fraud.

Really though, being the most honest crook among crooks still leaves you being a crook. That's why some countries have outlawed this particular kind of scam.


So now you have just jumped straight into calling me a crook. I'm sorry that Wavee or whatever site you went to took your money.

I honestly didn't know (and still don't) if you can make any money doing an honest penny auction site. We are just breaking even with this one so far.

The fact is that every time an auction goes up we have more risk than anyone else involved. If I put up a $500 iPad it could go for extremely cheap. The lowest one has ever gone for is 64 cents. That means we made less than $64 and still had to buy and ship that $500 iPad. And we have never sold anything for more than $26 which still isn't the $2600 you think it is because some packages give you more bids per dollar.

The legitimate complaint is when sites cheat. Which I would guess alot of them do. Using Facebook is not some trick to get people to trust us. Its a way for people to verify for themselves that they are in fact bidding against other real people.

How can you say that its a scam? Do you think we are just out there creating all these fake accounts with fake profile and personal photos and relationships etc. I can see maybe if we had 5 or 6 or even 20 users. But we have 100's of winners. That's a stretch even for the most paranoid and cynical of people.

Not everybody wins every time. But the data we have so far says that the majority of users that buy more than just a few bids are actually the ones getting all the deals. Its the people who come in and spend $24 expecting to win a $1500 item then leave when they don't. Those are the people who are losing. The users who are logical enough to see how the system works are the ones who get far more than they put in.

And some countries outlaw all kinds of crazy things, some countries are considering passing legislation to ban homosexuality so I guess we should all agree that its bad now too according to your theory?


I'm not so foolish to have spent money at any of those sites. But I do stand by my statement of calling you a crook. I don't believe that I will be able to convince you, but I do hope that I'll be able to convince others.

Let's give you the benefit of the doubt for a moment that you are actually honest. We'll say that you aren't running bots, fake identities, etc. That's fine. My basis in calling you (and those that run businesses like yours) a crook is not founded on that (though I have no doubt that other companies are doing as much, if only to boost the value and bidding on an item, but I digress).

Try to remember that the fundamental operating principle of your business being profitable is your selling the vast majority of your customers absolutely nothing. They aren't getting a good or service for any bid that doesn't win (which still costs them money). They get nothing.

The money to purchase those items must come from somewhere. If you are breaking even (as you say you are), it's not coming from the people who are "winning", it's coming from the people who are losing. If/when you are making a profit, it's not because the "winners" are necessarily paying that much more for an item (they won't have bid enough plus paying for the total value to pay for the item itself), it's because you've got more losers who are putting money into something without getting anything in return.

Your business is breaking even, and may eventually be profitable because of all of those who come in buying $24 worth of bids, failing, and leaving. Any business that requires it's customers be ignorant in order to make money is fundamentally a scam.

Also, your conflating countries making homosexuality illegal with countries making illegal a business that bases it's operations on exploiting the ignorant, is a fundamentally flawed argument. One is based on basic human rights to be who they are and behave in ways that causes no harm to others. The other is one that profits from people who don't know any better. One is a human rights travesty, the other is the outlawing of an enterprise with margins that organized crime wishes they could have (in the case of a "successful" site like Wavee and others). Trying to claim their equivalence, or that based on "my reasoning" they are equivalent, is dishonest, and really, troll-like behavior. That may fly in some forums, but it doesn't fly here. Try again.


> The users who are logical enough to see how the system works are the ones who get far more than they put in.

Your business model requires minimizing the number of those people and maximizing the number of suckers. There's a reason they're seen as scams and exploitative.


I had never heard of those before. Are they capable of working inside any web broswer? Looking it up right now.


Yes, you can reach a queue via a web browser using the proper api access you provide.

If you have 100 users, each one waiting for a message in their queue, then you can "broadcast" a single message to all of the queues (or a group) with one command. All the users waiting for a message in their queue will get a copy.

Another approach which is hack-ish imo, is to use something like jabberd to broadcast messages.


Mostly just because I've never used FastCGI before, and I have played around with making C/C++ servers for fun before. Seemed like the fastest solution and so far its worked out better than expected.


This is a bit of an oversimplification, but where CGI spawns a new process for each connection, FastCGI* starts the process once, then runs a loop to handle each connection, so the process startup, database connection, etc. costs amortize to essentially nothing -- many of the constant factors for working in a higher level language are eliminated.

FastCGI is worth looking into - a lot of popular webservers support it, and it's less of a complete model change than switching to an event-based system (e.g. node.js) or an MVC framework.

* Or SCGI, which is a newer, simpler design with similar goals.


Was it an auction site as well? If so which one if you don't mind me asking?


Yes, it was a penny auction site. I can't give the URL as it is not my website. I assisted them with development.


The reason it has to continually sync is that any user could place a bid at any moment. This makes the timer increase and top bidder change, so every user must be notified of the change. Its asking the server for how much time is left in each auction not what time it is in the real world. Sorry for the confusion.


Why don't you use long polling rather than sending a request a second?

You could even incorporate the timer into a single request.

    do {
        sleep(1);
        $seconds_remaining = fetch_auction_time_from_memcache();
        echo "<script>updateActionTime($seconds_remaining);</script>";
        flush();
    } while ($seconds_remaining > 0);


This is interesting. Would this work if I was on the site for say an hour? Or is there some limit to the amount of time you can send data like this? I have never tried anything like this. What is the overhead like?


I've only used it on smaller projects. Facebook use it on their frontpage for progressive loading (check the source for `<script>big_pipe.onPageletArrive(..);</script>`).

Longer running connections are a little more problematic, but some client side code should be able to handle the connection being closed. You just need to make sure your web server can handle the number of connections your are expecting. Apache is particularly bad for this. Something like nginx should perform better.


Not hard. The client could notice if the connection dies (JQuery has AJAX failure callbacks, for example) and then attempt to reconnect; that's the important thing.


I was going to suggest long polling as well. Seems to make way more sense than normal polling for this application.


Personally I'd go with simple Python WSGI app or node.js app. Actually even PHP can handle 150 reqs/sec (your load at 150 users with 1 req/s) if used as nginx+php-fpm+eaccelerator. By my measures it can actually do about 1000 reqs/sec.


Yes, it would handle it and we could have kept scaling the server up to handle more and more of it. With the C app all those problems went away. It has almost no footprint and uses almost no processor power.


The timers are all set differently, we can have 9 seperate auctions going at once and all have different times they end at. Also when someone bids the timers increase. So they are not only all different but all changing constantly. Its not just a single countdown that we could sync.


I completely bypassed apache all together. Apache is not used for the 1 second ajax call at all. The only libs i used were jansson for easy json manipulation and mysql++ for database access


Also because of the need for consistency and latency I'm not sure memcached would be a benefit because it could never be scaled anything but vertically anyways.


Memcached? Only vertically? Horizontal scaling is built-in in all memcached clients.


yes, I was just saying that we can't wait for replication, when someone places a bid all the others users must have that information immediately.


memcached doesn't do replication as far as I know. It will just have to do some requests second time. It still beats re-calculation on each request.


Replication is the wrong word for it. Key distribution is what you want. If a given memcache server goes down then the keys it was storing should get reloaded to a different one in your pool by your cold cache loading code.


On the frontend I was already using lighttpd, but I could have used memcached on the backend that was going to be the next step if the c app didn't work. It just worked so well I didn't have to worry about it.


I didn't mean to poop on your parade. I love writing servers too but if you have a public facing HTTP server there are a ton of obscure edge cases to worry, like some script kiddy DOSing your server by either opening a connection and keeping it open without sending anything or dribbling out a character a minute to circumvent your SIGALRM handler.

I'd think about switching back to a public interface that has been through these battles before. You could always keep your server up and use Nginx or HAProxy to front it for you and just pass the requests on.


Yeah I have run into some of those problems already. Thanks for pointing that out. You definately need a SIGALRM handler if you are thinking of doing something like this. But I don't really see how switching to Memcached is going to prevent a DOS attack. Not trying to be defensive, just really wondering if there is something I'm not getting about that.


I'm not trying to be offensive either :) I was just warning that putting up a public facing server is eventually going to make you a target. Using a battle tested server will let you concentrate on getting more people to use your app instead of fighting bored 13 year olds trying to bring your server down.

Good luck with your app!


Thanks! I understand your point, but a fork server is so simple I don't think there is much that can go wrong there, if it was serving more data I would be worried, but its meant to do a quick and short reply.


it's not called a forkbomb for nothing


http://en.wikipedia.org/wiki/Fork_bomb

Fork Bombs are easier to pull off from the command line. Not so much with DOS. I would say that loading a large webserver for each request would use up more resources than a tiny C program. Thats the whole point of the post.


You're right about the webserver being overload. Threads would be less expensive than processes.

I would use Go for this service myself. Defending against abuse is hard whichever way one goes.


Writing your own server in C seems a little crazy anymore. Just use a C++ framework like POCO or ASIO. POCO gives you a fast httpserver component with all the tricky stuff figured out.


I couldn't agree more. Nginx and HAProxy will seem like miracle workers after seeing Apache's performance.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: