- Mon Jan 02, 2017 2:59 am
#60265
marcelstoer wrote:jimlyke wrote:https://nodemcu.readthedocs.io/en/latest/en/modules/net/#netsocketon
I guess I am not a good programmer
It might also be that we're not explaining things well enough 
The thing tough is that our documentation is an API reference and not a tutorial. As the net module offers a low level operations a solid foundation of networking know-how is indispensable I guess.
What exactly is it that you'd like to know? What challenge would you like to solve using the net module?
Thank you, I am mostly trying to parse returns from GET methods (more ambitiously I am trying to orchestrate a distributed network of ESPs through REST-like API calls, but one must walk before running, and this means I need to nail a GET request before trying anything more elaborate). In the many examples and snippets I have tried to follow, I see a sequence of invocations of the form:
1. conn=net.createConnection(net.TCP, 0)
2. conn:on("receive", function(conn, payload)
<stuff> end)
3. conn:connect(80,s.host)
4. conn:on("connection",function(conn, payload)
5. conn:send(<stuff>)
end
)
6. conn:on("disconnection", function(conn)
Obviously, #1 is necessary to establish a client connection "object", for lack of a better term. The next thing I would think necessary is to actually perform a connection with a website, which is done by #3. I don't understand why this is not immediately next, but in most examples, it seems to be done in this particular order. To perform a GET request, we would send an appropriately formatted string, which is done in #4,#5 (i guess once we have a connection, then we should send something...). But then we expect to get something back (i.e., we receive a string/file back from the host), which is done in #2. And sometimes I see the disconnection statement (#6) which I guess seems to signify the end of this set of actions.
But this ordering seems to not follow the sequence of what happens. In the FAQ, I remember something about how the nodeMCU does things in terms of events and that statements either do not block execution or that they TOTALLY block execution (like the tmr.delay, which actually disables interrupts and appears to stop the CPU at a machine level). I am interpretting this to maybe mean we can order the statements non-sequentially. But if so, why not order them logically just to improve understanding, e.g. #1->#3->#4->#5->#2->#6.?
I also do not understand the whole notion of a callback. I am mimicking what others do and I more-or-less get things to sometimes work. Doesn't instill confidence.
I am also having name server problems and have to use ip #'s instead of names. I saw comments in the past about this, but I have so far been able to only get things to work using numbers for ip instead of host/domain names.
