Jacques1

No, you need to know if it was successfully processed by the target application, which is much more than a simple TCP acknowledgement. If you want an application-level success message, you have to implement it yourself (as stated earlier). That is, the JSON receiver must send its own data to tell the sender that the document can be deleted. HTTP is a good all-around tool, and JSON over HTTP is very common. Yes, I think it's the right choice when there are no special requirements. If traffic ever becomes an issue, you can still use compression (which is very effective for text-based formats).

No. TCP acknowledgements are processed deep inside the operating system. You cannot even see them at the system-call level below PHP. Newline-delimited JSON is a de-facto standard. I've also seen (but never tried) several stream-based JSON parser for PHP which can extract documents from byte streams. Like I said, sockets are low-level concepts. If you expect this to be super-easy, you've picked the wrong approach. Why would the sender resend the data? I think you're still missing the fact that TCP is a realiable protocol which takes care of all those details. You never have to worry about duplicate or lost data. You just push the bytes of your JSON documents into the sending buffer and read them from the receiving buffer. When you're talking about cURL, you probably mean HTTP. Yes, HTTP is a protocol on top of TCP, yes, it has some overhead. But it hides all the ugly details, and you should be very familiar with it. With HTTP, you can just send a JSON document. Not a stream of bytes.

That is pretty much the way. There is no inherent the-JSON-document-has-been-received state in TCP. You have to concatenate the JSON fragments you get and either run them through a parser which supports streaming or separate the documents with a special character like a newline or use a length prefix in front of each document. The “finished” state must be implemented by you at application-level. If you want the sender to know when a document has been received: It doesn't. The write() method passes the data to a React buffer, React passes the content to a kernel buffer, and then the operating system takes over to actually generate and send the TCP segments (which may require many attempts and some time). Everything else is out of your control. You could make the receiver send you some kind of acknowledgement for each JSON document, but that won't be very useful.

Ask the customer how exactly the state-specific version looks like (ideally with a screenshot). This should be easy to search for in the database and/or code. Note that cookies can also be set with JavaScript, so you could try another code search. If nothing helps, try to reproduce the customer's situation as accurately as possible. Use the same role (or even the same account), try a different browser, maybe even use a proxy. If possible, also ask your customer to try different browsers so that you can rule out any client-side influences (browser extensions, malware, ...).

The receiver will not get data in the wrong order. TCP is explicitly designed as a reliable protocol, which means you will get the complete data in the right order. If a segments gets lost, it's resent, if segments are received in the wrong order (for whatever reason), they're reordered according to their sequence numbers. That's why I said that you're conceptually dealing with a byte stream. The segments are just implementation details which are handled by the operating system. No. TCP streams by definition don't end unless you close the entire connection. The class does implement this. That's actually the whole point of the buffer: It holds the data until it has been sent and acknowledged by the receiver. What you do is pass a JSON document (or chunks of thereof) to the write() method. If the buffer is full, you have to wait for the drain event to send the next document (or chunk) etc.

TCP is dealing with streams. That is, you send and receive a sequence of raw bytes. There is no concept of “messages” or anything like that, so turning the byte stream back into JSON documents is your job. How the strings you send are split into TCP segments is up to the operating system (see the TCP protocol). There's no guarantee whatsoever that a single PHP string will be sent in one go. You may have to repeat the sending procedure multiple times until all data has been acknowledged. As to the return value of the write() method, see the documentation. A fair warning: Sockets are low-level constructs. This is not like HTTP where you (mostly) get the complete content and can just access the data.

What problem?

The code doesn't make any sense to me. It's not even clear what you're trying to do. What is the point of the random number? What is the matter with all that browser refresh stuff?

The client essentially subverts the type flexibility of InfluxDB by appending an explicit “i” whenever it encounters a PHP integer. If there's no better client, cast the arguments of the Point constructor: $point = new Point($measurement, (float) $value); Or change the source code.

You really, really need to develop a more systematic and professional approach to problem solving. This is way too much randomly-fiddling-with-stuff-and-hoping-it-somehow-helps. Is there a problem right now? Not in some hypothetical future. Now. If there isn't, stop those nano-optimization attempts that don't do anything but keep your busy for yet another week. That's the right solution for the entire thread. If the user requirements change in the future, you need to systematically identify the problems and solve those specific problems with the right tools. Adding random “optimizations” just-in-case not only makes no sense. It's objectively counter-productive. By trying to solve your imaginary traffic problems, you've created real problems: Validation has become so obscure that you need multiple posts to even explain it. The data format is close to unreadable. And worst of all, you're wasting your time instead of spending it on useful features, code quality etc. If there was a real problem and a specific goal (e. g. “My customer is sending 10 MiB of JSON data per second and needs to reduce traffic by 50%”), I would happily discuss all kinds of compression methods, alternative formats, custom protocols and whatnot to help you reach your 50% goal. But there's neither a problem nor a goal. It's all just made up.

Why on earth do you keep storing punctuation marks only to replace them daily? Why are those characters even a problem? And if they are, why do you not reject or replace them immediately when you receive the input?

Early versions of InfluxDB did have issues with numeric types. However, this was fixed back in 2015, so I guess the answer is: Update your software.

InfluxDB interprets all number literals as floats, unless you're using some very old version.

Hence the measuring part. Real optimization almost always comes at a price, which is why it's done for a specific goal, not because the programmer feels like it. So before you jump to any techniques, figure out the actual requirements and their priorities.

Looks like this is the real problem of all your recent threads. Of course. Ever heard of compression? BSON? Or even crazier: Measuring to see if the problem is real or just imaginary?

Again: Why? As I already said, PHP and virtually all other mainstream languages can convert integer types on the fly: var_dump(128 + 0.5); // float(128.5) So what kind of application “needs floats” and is unable to handle 128 as opposed to 128.0?

And that is important for what reason? PHP converts numeric types on the fly whenever necessary, so insisting on a float 128.0 as opposed to an integer 128 makes no sense.

We need to see your code. Since you obviously struggle with the basics of JavaScript, there may still be plenty of other technical issues which break the whole thing.

If you're talking about actual insults, you need to report those posts so that the moderators can take the appropriate steps. If the posts are within the limits of the forum rules and you just don't want to read them, you can use the 'Ignore' Preferences in your profile.

Your config scripts starts with a blank line. This is output which gets sent to the client and prevents any subsequent header() calls. You have plenty of other output, because you've unfortunately adopted the spaghetti-code pattern where you randomly mix PHP code with HTML markup. You should completely separate the different languages: PHP on top, HTML at the bottom. <?php // PHP code goes here ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Title</title> </head> <body> <!-- HTML markup goes here --> </body> </html> If you're unable or unwilling to fix the code, your only workaround will be to enable output buffering in the PHP configuration.

You cannot do this with PHP alone, because a long-running PHP script delays the entire response so that the user just sees a blank window. You need JavaScript. More specifically: You need to trigger the PHP script with Ajax. The spinning wheel is called a throbber, and there are plenty of libraries. When you've received the response, you hide the throbber and insert the data from the PHP script into the page (you should make the PHP script output JSON data rather than a plain string). Start with the Ajax part.

I have no idea what you're saying. The equivalent of <input type="text" name="username" value="<?= isset($_POST['username']) ? html_escape($_POST['username']): '' ?>"> using your default value stuff would be $defaults = [ 'first_name' => '', 'last_name' => '', 'username' => '', 'password' => '', ]; # Any missing elements get the default value. $_post = array_merge( $defaults, array_intersect_key( $_POST, $defaults ) ); <input type="text" name="username" value="<?= html_escape($_post['username']) ?>"> That's more code, it's more complicated, and it's just confusing. So why on earth would you do that? You've tried your idea for two weeks now. I think it's time to give up.

You understand that IP addresses can easily be changed, right? What does this function do? Why should it only be executed every 24 hours?

You don't need no regular expressions. Just look at the output of the command in the console and then split the string at the right characters. Surely you can recognize a newline and a tab. In my case, that's foreach (explode("\n", $arpOutput) as $host) { list($ip, $mac) = explode("\t", $host); echo "IP address: $ip, MAC address: $mac<br>"; }

The arp-scan on my machine uses newlines to separate the hosts and tabs to separate the IP address from the MAC address: <IP> <MAC> <IP> <MAC> ...