TCP/IP Offloading, Should you use a integrator, Silliest file format ever, Legal data theft?

Post date: Aug 14, 2014 2:26:49 PM

TCP/IP Offloading

One guy wrote light TCP implementation using Python. First of all, if the device is running python at all, then it's already super powerful.

Problem is that using PPP or SLIP doesn't relieve you from having to implement at least some kind of crude TCP stack.

But if you use TCP offloading, then you can communicate using TCP as cheaply as doing any traditional serial communication. I've seen those crude TCP stack implementations and those are barely LAN capable. Using those over Internet wouldn't be a great idea. Often these TCP stacks are used just as serial - TCP converters. Using RWIN of 16 (max) bytes due UART buffering limits etc. Not sending ACK before whole 16 byte is cleared and so on.

So with really low end devices, it's better to off load TCP to custom hardware. Many embedded devices use that approach. In such cases you'll only call to IP address and port, and when it connects, you'll have your TCP/IP connection in pure serial. TCP-modems isn't any different from other good old Hayes modems. It's just dial-up over Internet and TCP.

Should you use a integrator or not?

Often I feel like using additional integrator is just going to make things more painful. First of all, they're obfuscation layer, causing problems, adding delays, etc. In case of direct integration, it's trivial to check what's being delivered and fix it if it's somehow incorrect. But if you're using integrator, it's all gone. There's never ending discussion if something is sent correctly, if it's lost or delayed due to integrator and if the integrator message conversion is working correctly.

This is basically just like working with outsourced developers. Simple things could take a lot of time, when you could have done it your self in fraction of that time. They don't understand concepts and do stuff that's barely working. But I guess this isn't news to anyone.

Silliest file format ever CSV in XLS

As doing integration stuff as usual. I asked them for a data format specification. They told me that they're using xls files for data transfer. Well, ok, I can live with that. But when I got the example, I didn't know if they're joking. But after all, they weren't.

This gotta be the coolest and smartest data format around.

Data A; Data B; Data C;

Ok, does it look like CSV? Yes, it does. But that's not all. It's actually A column of XLS file. So all of this data is stored inside XLS container in column A rows.

If they would use CSV, that would be just fine.

If they would use XLS, that would be just fine.

But combining those like this is just ridiculously silly and worth of daily wtf.

I just wonder what integrators would say, if I would tell them that I prefer actually XML files, which are just an envelope for base64 encoded animated gif images and there in the comment field must be the JSON payload data. Btw. I'm also checking that each image is unique, and regular manual checks are done, which are used to confirm that images actually do contain well known Internet meme characters.

Companies forced to steal data from their customers?

Microsoft is giving data to US agencies, even if users are foreign and data is not stored in US. So if you think using MS European data center(s) provides privacy, you got it wrong.

It's quite likely that same unfortunate rules apply to Google, Yahoo, Twitter and Facebook as well. Great question is, if it's enough that the company hosting the servers is American? If there's small European business, using Amazon Servers in Europe, is it still all your data belongs to US fair game?

Can this kind of approach be extended to other than server hosting? Let's say high tech company in Finland is using Symantec anti-virus. For some patent troll reasons (or what ever), US court decides that data from company should be extracted. Now, can they force the US anti-virus company, which got access to the data, to get it? Technically this is trivial trick to do. So instead of server hosting, we're now talking about software. In technical terms, it's irrelevant how the access to the data is gained. Maybe using Windows is still a very bad idea. This also means that the cloud question is irrelevant also. Because most companies do not completely write their own software, they buy it from someone, who's able to most probably steal data handled by the software. Or in case of administration utility programs, all data on that system.

People are often afraid of the cloud, but they forget that on-premise systems can be similarly targeted via using bit different channels. Do you really use automatic updates? It means that software can be changed on fly to steal your data, and returned back to standard version so that you don't even know about it. (I've been warning about this several times. In many cases updates aren't even properly signed, which basically means that it's possible for 3rd parties to do exactly that.)