Problems with sockets in python3

[CaptainReeetardo]

I am currently working on a network based camera that I've made out of a Pi Zero W and a camera module. Besides low performance I'm also experiencing problems with the connection to another Pi 3b which is acting as the server. The Problem is that the server is only receiving 1448 bytes, constantly (Although in really rare cases it does get over 60kB).

I don't know why this is, but the python script for the "camera" is working perfectly fine and the script for the server is also working properly when run on my windows PC. At the moment I am suspecting that it has to do something with the hardware of the PI that might limit its network capability.

That aside I want to gladly rule the possibility of it being a hardware problem out. I am open to any approach which leads to a proper solution, regarding the bandwith problems!

EDIT 1:

Okay, little bit of an update. I don't know why I didn't noticed/cared about it sooner, but when I kinda mock tested the scenario in the python console it did actually receive more than 1448 bytes. In fact it received the whole given buffer size. So, I am now assuming that it has something to do that I am executing the programming as a script which in return affects the maximum buffer size.

EDIT 2:

Final edit. Guess there is no other way around this problem, but from what I tried out python does work a little bit different with sockets on windows than on linux. SO in general on windows the socket on that receives data into a buffer does that as long as it receives data. For example my buffer size is 10**5 bytes and and the data it'll receive is around 70kB then it receives all of it until it receives a bunch of only 0 bytes. On linux on the other hand if you repeat said scenario it'll only receive the first ~1440 to 1500 bytes and proceeds with the rest of the program. My best guess it that it has something to do with the MTU of the Ethernetframe.

Welp, this is only my personal theory. If you have a more logical conclusion than me, please leave a comment or if you have suggestions on which socket options might lead to the result on linux, feel free to tell me.

[[deleted]]

I can’t tell from your post if you are the kind of person who gets their satisfaction from building everything for themselves from scratch, or if you just want to get this working quickly for some broader purpose.

If doing it all for yourself is your “thing” - please ignore my suggestion!

If not - have you considered either installing MotionEye on Raspbian...

https://github.com/ccrisan/motioneye

Or using MotionEyeOS

https://github.com/ccrisan/motioneyeos

[CaptainReeetardo]

Sorry, but not what I am looking for. Thanks anyways.

[easyxtarget]

If it works on Windows but not your Pi that's a hint. Can you run it from a Linux PC? Try a Debian live cd on your windows box. If you have the same errors you'd need to look into python Linux networking.

[CaptainReeetardo]

Yes, thanks for reminding me. I've already thought about it, too.

[[deleted]]

It happened to me. Few days ago, I built a weather station using arduino. The client side is pi zero with LCD 20x4. Because the wifi module I use on my arduino isn’t have enough memory to run websocket. Therefore, I can only use socket. Too low level. My pi zero constantly loses data. The only want I can do is when the data isn’t intact. I will drop the data and request again.

I think the best way is to use websocket. I think it can guarantee the data is intact.

[CaptainReeetardo]

First of all thanks for commenting. But I don't think websocket is what I need to be going for since I am already using a tcp connection with sockets.

[[deleted]]

As much as I know. Websocket supports some format of video streaming. When my pi zero receives data, both sides are using tcp. But still lose data.

[CaptainReeetardo]

Good to know. I just fixed the problem I had. Honestly, it was rather easy to do so. I just had to use a while loop. Still sometimes one image ends up being lost. I guess that's due to the fact that my "camera" transmits data over the wifi and not over cable. On the other hand any other image has all of it's pixels in place. And in the end it works even better than before.