Multiple conn:send() not working

[positron96]

When I was on a stable build (0.9.6-dev_20150704), the code like this worked correctly:

    connection:on ("receive",
    function (conn, req)
        conn:send("HTTP/1.0 200 OK\n")
        conn:send("Server: ESP (nodeMCU)\n")
        conn:send("Content-Length: 1\n\n")
        conn:send("a")
        conn:close()
    end )

This worked for a client socker as well as a server socket.

Now I moved to dev build that says:

NodeMCU custom build by frightanic.com
    branch: dev
    commit: d8c6fe0b25142f6ae866c18c3bcb3d0538d4baaf
    SSL: false
    modules: node,file,gpio,wifi,net,pwm,tmr,uart,ow
 build  built on: 2015-11-03 20:47

And only first conn:send actually sends, all following calls get silently discarded. I now need to store the lines into a table and join table into a string which is probably a waste of memory.

Is it a bug or is it intended?

[TerryE]

The outcome of your code is indeterminate as network requests are treated as separate tasks by the SDK. Ignoring the fact that you should marshal your sends where practical, something like this would work:

  connection:on ("receive",
    function(sck, req)
      local response = {"HTTP/1.0 200 OK", "Server: ESP (nodeMCU)", "Content-Length: 1\n", "a"}
      local function sender (sck)
        if #response>0 then sck:send(table.remove(response,1))
        else sck:close()
        end
      end
      sck:on("sent", sender)
      sender(sck)
    end )

One network call per task and no ordering problems. And yes this is could be viewed as bad coding to have two semantically different variables both called sck but in reality they both point to the same userdata. This really falls under #719 unless this also fails, but I'll give you a chance to reply first 😄

In reality, I'd never encode it this way because your algo implicitly assumes that you'll get a bare request and this rarely happens. HTTP 1.1 is a complex protocol yet everone using it seems to make a load of dumb assumptions and then wonders why their code is flacky.

[jmattsson]

Is it a bug or is it intended?

This is a result of changes within the SDK. Pre-1.x the SDK seemed willing to buffer up contents from several send() calls despite it not being officially supported, but that is no longer the case. I suspect (but haven't verified) that this happened when they freed up substantial amounts of RAM for application use.

So well, this is neither a bug nor intended, it's simply what's being imposed by the SDK.

[positron96]

Hello Terry. The code you provided works, as does concatenating the table into string, but sending a table with recursive ''''sent'''' events is not very intuitive to say the least. I'll sacrifice memory and stick with table concatenation as more clear way.
Also, could this behavior be documented anywhere? I believe I'm not the only one trying to send data with several successive calls.
(Btw, my example code is not the whole piece of http request handler of course:-)

[TerryE]

@positron96 read my Unofficial NodeMCU FAQ. It really need a major update but it does explain this sort of issue. As Johnny says, this was never supposed to work but it did on 0.9x unless you died on memory and PANICed

[dwery]

This seems to be a common issue, it happened to me too as it worked on 0.9.5. maybe the http example or documentation could be amended or a better example provided. I resorted to concatenating a couple of strings but it's not very classy,

[nanodeath]

Even if this is "as intended", it's still confusing as a new user. I've added a new Note section to the docs, which ultimately links back to this page; feel free to update it if it needs it.

[makefu]

@TerryE based on your response i tried to write a bit larger file (> 1024bytes) but i have the issue transferring the file in a chunked manner because file IO is slower than the socket IO.

What is the nodemcu way to solve this issue?

[Hellsy22]

Why not fix this on firmware side? I mean let's return the queue.
Most of languages care about sending data to socket (syswrite, socket.write, print SOCKET etc) - for user it working just like a black box.

[TerryE]

@Hellsy22, Espressif broke backwards compatibility because the 0.9x approach burned memory resources and caused all sorts of instabilities. We don't see it as our job to undo sensible SDK changes. The SDK is task-driven, not procedural. We can't change this.

[Hellsy22]

"We don't want to burn memory resources by queueing send on SDK side, so we force all users to burn twice more resources by queueing at the LUA side". Ok, I got the point.

But what if I'll make pull-request with a new method called "qsend" working as old fashioned send? Will it be ok or still unaccepable?

[TerryE]

Why bother? Replicating the old functionality will be really complex and memory intensive. Getting it right is going to be difficult. It's just so much easier to code up your Lua correctly in the first place.