Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kindly request for wifi packet lenght optimization #3

Open
antonmeyer opened this issue Mar 13, 2016 · 7 comments
Open

kindly request for wifi packet lenght optimization #3

antonmeyer opened this issue Mar 13, 2016 · 7 comments

Comments

@antonmeyer
Copy link

when I look at the wireshark trace I see a lot of small packets for a single SOAP request.
I guess it is from the bunch of ethClient_write_P.
I also guess that the client code should care about MTU and MSS.
I also assume that your buffer-size of 50 byte is a tribute to the HW-limit.
With ESP8266 this looks better.

@nitech
Copy link

nitech commented Nov 1, 2016

Since you are asking a wifi-related question, I am wondering what changes you did to make the Sonos Arduino api work with a wifi board?

I am trying to get this working on a LoLin NodeMcu 1 board.

I've done some changes to SonosUPnP.h, like for instance replacing references to Ethernet with WiFi.h, but I don't know if I am on the right path.

@antonmeyer
Copy link
Author

look at my fork
should work, i was a bit lazy in the last month (busy with other projects)

@nitech
Copy link

nitech commented Nov 6, 2016

Thanks. I'll check it out right away!

@nitech
Copy link

nitech commented Nov 6, 2016

Yep, this seems to be working great. Thank you so much :-)

https://github.com/antonmeyer/sonos

@tmittet
Copy link
Owner

tmittet commented Nov 9, 2017

The amount of memory available is very limited. As you say buffer-size of 50 bytes is to avoid memory issues. I'm no network expert, why is the small packet size a problem, performance?
I'm up for suggestions on how to improve this. I've made you a collaborator. Commit improvements or make a pull request. It's up to you :)

@tmittet tmittet closed this as completed Nov 9, 2017
@antonmeyer
Copy link
Author

antonmeyer commented Nov 9, 2017

hi tmittet,
when I think twice my request is a bit academic approach. I found it a waste of network resources to send several packets with all its overhead, which the receiver has to reassemble. Also in terms of reliability a packet loss is more likely with more packets. But finally for control traffic with very low amount of overall traffic it does not matter.
Normally you have a network software stack and MTU size is the parameter.
I started with a ESP8288 which does not have hardware limitations like a attiny.
I guess it is not worth to change it, unless you want to include streaming to your project.

@tmittet
Copy link
Owner

tmittet commented Nov 10, 2017

I totally support changing it if you want to do it :)

We could add a condition like:
#ifndef SONOS_LOW_MEMORY_MODE
// Current implementation
#else
// Optimized implementation
#endif

@tmittet tmittet reopened this Nov 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants