@chrishamm

I have installed the development environment and implemented keep-alive for HttpResponder.

Its has no impact on browser calls, those sockets get closed even when Connection: keep-alive is set.

If the Rrf-Keep-Alive: force header is set, keep-alive starts working for a single socket. (so max 1 concurrent open socket)
__LPC17xx__ is also checked and, if set, disables keep-alive.

I have to do some more testing, but all seems to work smooth.

If interested I can create a pull request, for you to verify?

Cheers
Gerd

@gloomyandy thanks! Figured out I had to install a more recent arm toolchain

@gloomyandy thanks! Figured out I had to install a more recent arm toolchain

@chrishamm

Ok, I had to install a more recent ARM toolchain (12.2) and after changing ArmGccPath and adding CrcAppender to the PATH, it builds.
But on generating the binary file, I get:

Generating binary file
arm-none-eabi-objcopy -O binary "/Users/gerd/Documents/Projects/Projects/Duet3D/RepRapFirmware/Duet3_MB6HC/Duet3Firmware_MB6HC.elf" "/Users/gerd/Documents/Projects/Projects/Duet3D/RepRapFirmware/Duet3_MB6HC/Duet3Firmware_MB6HC.bin" && CrcAppender "/Users/gerd/Documents/Projects/Projects/Duet3D/RepRapFirmware/Duet3_MB6HC/Duet3Firmware_MB6HC.bin"
Failure processing application bundle.
Bundle header version compatibility check failed.
A fatal error occured while processing application bundle
make[1]: [post-build] Error 159 (ignored)

any ideas?

@chrishamm

When moving to the 3.5-dev branch, I get the following build error:
unrecognized option '--no-warn-rwx-segment'

I'm using ARM toolchain version 10.3-2021.10

Should I use a different one?

Thanks
Cheers

Gerd

@chrishamm

I have installed the development environment and implemented keep-alive for HttpResponder.

Its has no impact on browser calls, those sockets get closed even when Connection: keep-alive is set.

If the Rrf-Keep-Alive: force header is set, keep-alive starts working for a single socket. (so max 1 concurrent open socket)
__LPC17xx__ is also checked and, if set, disables keep-alive.

I have to do some more testing, but all seems to work smooth.

If interested I can create a pull request, for you to verify?

Cheers
Gerd

Ok, it all works

I had to add the PATH in Eclipse.

Project > Properties > C/C++ Build > Environment

Not sure why I had to do that, since the application is accessible in a terminal window

@dc42

Thanks! That solved it, now the project build without errors.

/bin/sh: crc32appender: command not found

That is strange, I have added it to my PATH

gerd@Gerds-MacBook-Pro ~ % whereis crc32appender
crc32appender: /Users/gerd/Documents/Projects/Projects/Duet3D/RepRapFirmware/Tools/crc32appender/macos-x86_64/crc32appender

What could be the issue?

Hi all

I have followed all instructions on how to start with RepRapFirmware development environment on macos.

https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware

The only difference, I didn't use homebrew, but installed gcc-arm-embedded from package (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads) and eclipse from direct installer.

All the other steps are the same.

CoreN2G, FreeRTOS and RRFLibraries build just fine.

RepRapFirmware (build configuration Duet3_MB6HC) however gives me errors.

It seems that uint32_t is undefined, so I add:

#include <stdint.h>

in src/libc/nano-mallocr.c

That gives me the following error:

Now there are multiple definitions of _malloc_r

Renaming src/libc/nano-mallocr.c to src/libc/nano-mallocr.c.ignore leaves me with:

I have no idea where to look next.

Also, I suppose it's not ok to remove src/libc/nano-mallocr.c , but then again, why did it say that uint32_t is undefined in the first place?

Am I missing some setup?

Thanks
Cheers

Gerd

@chrishamm

I am using a Duet 3 MB6HC v1.0

There is some support implemented, but not for every command.
(text/plain commands don't have it)

And currently keep-alive is disabled, so Connection header is always set to close.

It has been tested in the past, but not sure it has only been disabled due to resource use ... there could still be other issues.

I would allow keep-alive for following conditions:
#1: Connection request header is set to keep-alive
#2: a custom request header is present (so browsers and other connections that set keep-alive by default are locked out)
#3: only one keep-alive socket is active concurrently
#4: read timeout of 2 seconds is plenty enough to automatically close the socket

This way there is no impact for default use.

At the moment I have no development environment installed and I don't have much time right now, but I would definitely look into this in the future.

@chrishamm

I am not using duet3 in SBC mode, I am developing my own custom controller and want to remove layers of complexity, if possible.

Looking at the code, keep-alive is implemented, at least partially, in

src/Networking/HttpResponder.cpp

I have found several lines where Connection is set to close and other lines where a keepOpen variable is used to set close or keep-alive.

I also found a line where the socket is kept open

Commit(keepOpen ? ResponderState::reading : ResponderState::free, false);

And other places close it straight away

Commit(ResponderState::free, false);
//or
Commit();

In GetJsonResponse I have noticed, keepOpen is set to false and never changes.

bool HttpResponder::GetJsonResponse(const char *_ecv_array request, OutputBuffer *&response, bool& keepOpen) noexcept
{
	keepOpen = false;	// assume we don't want to persist the connection
...

To me all this looks like 90% of the keep alive support is already in place?
I would try to finish the implementation myself.

I could check for the existence of an extra custom header and, if present, keep the socket open. This would prevent browsers and other connections that send keep-alive from actually keeping the socket open.

The HttpReceiveTimeout is set to 2 seconds, so the socket will close automatically when not used.

I only need 1 connection for my project, so I could also try to implement that only 1 socket can be kept alive concurrently, the rest is ignored.

Do you know of any other pitfalls?
Keep-alive apparently has been tested in the past?

Thanks
Cheers

Gerd

Hello All,

This a an old thread, I know, but I would love to see the keep-alive feature supported for rest-api in future firmware updates.
(https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests)

I understand that keeping sockets open has a resource impact. But maybe it can be up to the user to decide what is important in a particular situation? And frequent polling has a resource impact too...

For my project I am using a Duet 3 MB6HC v1.0 standalone and I do not use the DWC at all (updates via bossa). I am developing specific controller software and rely on good and fast socket connections.

So, maybe this feature can be enabled via a setting, for those who would benefit from it?

Ideally, I would love a websocket, so that I do not have to poll anymore. But keep-alive is a great alternative. Possibly with a (configurable) timeout of 1 to a few seconds?

Hopefully you would reconsider

Thanks

Gerd