I am quite sure there are great members with years of knowledge that will laugh about my questions, but I didn't find anything about it. Because I have started with PHP just a few months ago, and I will develop probably for really long time, I have decided to be part of this community.

Now, about the question itself.Note: Forum member, you probably can answer the question without reading the methodology.

Client in Java request an operation to a LAMP server.

The really sort version of the methodology: users connect to the webpage 'A', which determines which IP's are blocked, with operations can be done for every specific user, and then, if there are sockets available (ports that can be open,etc..) the user receives the port to proceed (and in the server side it is opened a socket there), in case no ports can be opened (or maybe because we don't want) I thought as alternative method, the user receives a second url (webpage 'B') to proceed with the same operations as in the socket, but thru the tcp80, and meanwhile in the socket is a normal "speech" workflow (user->socket, socket->user, user->socket,...) with the alternative method I need send new parameters to the webpage B (user->B and B answers by echo (the server stores the info exchanges in db until it receives the next step of the process from user,...).

I thought sockets were faster (no headers like HTTP GET...), but I am really surprised that it isn't. So, I have been fighting against sockets for 1 week, to understand that the alternative method is in fact the best method.

I have done some benchmarks with different types of operations from users, and as average:

All tests are done in localhost.

test A:5 users. Every 4 seconds a different user request an operation type 1.Time in finish the operation (since user request til server finishes the operation)Sockets: 8 s. (and some sockets are blocked, TIME_WAIT states,... but this is maybe because of the localhost)Webpage: 1.6 s.

Now with operation type 2.Sockets: 4 s.Webpage: 0.9 s.

test B:5 users. All users request at the same time an operation type 1.Sockets: 11 s.Webpage: 4.5 s.

Now with operation type 2.Sockets: 7 s.Webpage: 3 s.

Now, the question: Why? Why I thought that sockets would be better?. Looking to the results, why I should consider in the future to try with sockets if it is so slow? What do you recommend me?

If you have something that is already built-in and if it is faster and useful to you then use that. In this case, you say that the so called "browser" is better. In that case, use the browser.

But, there will cases or situations where you do not have anything "ready made" and the only solution to implement it (your networked application problem) will be to write your own method from scratch. In this scenario go for socket programming. You can use any programming language for this as long as it supports the Socket API.

So, as summary, if your OS and Programming language that will be the source code of the app to communicate with from the server supports those "built-in functionality like a browser", use common http 80 requests. So, almost in every PC nowadays doesn't make sense to use sockets instead of http request if we are using php.

In other cases, probably embedded systems and so, sockets.

I remember to program Java to Java with sockets, because it was the only solution if I wanted to avoid communication through a server with other language.

This book may not tell you when to use socket programming but will give you a feel (trend) of what type of applications programs use sockets. But, again there are no strict rules, it is you who will decide based on the situation. For example: Even if I have a built in method that will satisfy my need but if I find that it (the method) is not reliable (as it is buggy), then I will go ahead and write my own method. In another instance I might go ahead and use an open source library even if I find that it is not reliable. So, everything depends on the situation