GET or POST from ARMweb

[YahooArchive]

Bruce,

Have you ever considered adding a "CGIOUT" to ARMWeb, that makes outbound HTTP
requests to other hosts? It wouldn't need to return a bunch of data to the
program, 255 bytes would be fine (it could RST if the remote host tried to
return more.) It wouldn't need to support the POST method, GET would be enough.

This would be EXTREMELY useful, it would open up a whole realm of opportunities
to use an ARMWeb.

Specifically what I have in mind is remote security gate management. To get an
IP camera with digital in and out ports adds $several hundred to the price of
the cam, and they typically only give you one of each. Also, if you want/need
to manage it from a PC you must maintain a video stream.

An ARMWeb could monitor several inputs, like multiple PIR's, open/close signal
from the gate, light sensors and more. And it could make good use of multiple
outputs to open the gate, turn on white and/or IR illumination, sound an alarm,
detonate strategically placed chunks of thermite -- no wait, wrong project,
scratch that, and replace it with "etc".

But it would need CGIOUT to really make this role, because with that it could
control the camera.

-MM

[YahooArchive]

Wow. I was just about to buy an Armweb to something similar...

James (Sent from my AT&T phone )

Mark mmcginty@dbunwired.com> wrote:

[YahooArchive]

We are taking a look at this.

So far we've done this kind of thing with UDP.

But with some restrictions we might be able to add CGIOUT.

[YahooArchive]

Bruce,

Did you ever make any headway on this?


Thanks,
Mark

[YahooArchive]

For a long time people have asked for client side services on the ARMweb, and we
thought it would be too involved.

But it finally go through to us all most of you really needed was the ability to
do a GET or POST to a server, and in most cases you would ignore the data the
server sends back. (we do return the first 256 bytes)

[basicchip]

Here is an example of using GET/POST in a BASIC program on an ARMweb

[mmcginty]

Nice!

I reviewed the example source, looks mostly straight forward...

Just to make sure I understand, it says (paraphrased) ARMWeb sends a SYN frame, waits up to 15 seconds for SYN ACK, sends the HTTP request frame[s] and waits up to 5 seconds to receive ACK[s], then the inbound response is received asynchronously on port 80? So 80 is both source and destination port for the outgoing request? I assume it ACKs and drops any additional frames needed for the response after the first, and that those extra inbound frames don't interfere with CGIIN?

Now here's the critical questions: it says:

' During an HTTP GET or POST request program execution is blocked.
' All TCP/IP functions are processed but the basic program will not respond.

So if an inbound CGI comes in while the request is being sent, what happens? And then...

' If the basic program receives any CGI input during this process everything is messed up.

I assume this applies while a response is inbound? The basic code has no way of knowing whether an inbound request was received? And the host that sent it gets no indication of failure?

Also, I'm not sure I get the DHCP requirement...

1. It accepts a numeric IP address so DNS doesn't seem to factor in. (And even if it did, why wouldn't statically configured DNS work equally well?)

2. If the destination host is on the same subnet, a gateway isn't necessary, a frame only needs to be forwarded to the gateway address if the destination is unreachable (the so-called no-host route.) I would suppose most routers will go ahead and relay frames to other hosts on the same segment, but when source and destination are on the same segment, there doesn't even need to be a router connected.

I would concede that routers are so cheap nowadays virtually everyone will have one -- maybe always sending to a gateway lets it out of processing ARP most traffic/it only needs to know the MAC of the gateway? But again, even if a gateway was strictly necessary, why wouldn't a static configuration work just as well? (This requirement is work-aroundable, given a DHCP server that supports reservations based on MAC address, I was just curious.)

All a little scary but still exciting!

-MM

[basicchip]

The main limit is RAM, we only have 32K total, and have a single framesize buffer that we share between CGI and GET response. So if multiple requests come, you get the last one. The intention is to offer low total bandwidth Ethernet connectivity on the TCP side.

We have run pretty high UDP traffic in a data gathering situation.

Remember, I'm playing whisper down the lane, as Mike does the network stuff, I do the compiler and GUI.

[mmcginty]

Well let's put Mike on the horn!

I'm just wondering why it couldn't just not ACK an inbound request frame when it can't process the request? That way the requesting client would assume the frame was lost and would retry it after timing out. The possibility of an indeterminate response makes it difficult to code a robust client -- request failure is not ideal, of course, but it is workable, as long as the client knows of the failure.

Oh yeah, meant to ask, "ARM7 Ethernet Microcontroller" is ARMWeb rebranded?


-MM