• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

How would you design a background C# application to accept external commands?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

  • BlueSharp
    replied
    Originally posted by woohoo View Post
    I've not read it properly but it annoyed me in the past that azure functions had a low timeout, especially as I used them much like scheduled jobs.
    Azure functions only have low timeouts if hosted in the consumption based plan. Host them in a App Service plan there is no timeout.

    Leave a comment:


  • woohoo
    replied
    I've not read it properly but it annoyed me in the past that azure functions had a low timeout, especially as I used them much like scheduled jobs.

    Leave a comment:


  • minestrone
    replied
    Durable Functions Overview - Azure | Microsoft Docs

    Leave a comment:


  • minestrone
    replied
    Originally posted by woohoo View Post
    Fair enough, but honestly, seems a very simple approach given the requirements. Doesn't seem any more complex that writing azure functions to start processes, does the timeout on azure functions not limit this approach?
    You know after I posted that I realised that it sounded over critical of your suggestion, which is wasn't, sorry for that, more the conditions of the requirements that have been set.

    Leave a comment:


  • woohoo
    replied
    Originally posted by minestrone View Post
    I've written pretty much this exact system, although it was java threads and CORBA waiting on multiple other systems connecting.

    It was about 15 years ago though and I wouldn't even entertain that kind of architecture now. If pushed and as said I would be more inclined to fire off new processes as at least they are viewable on the OS.
    Fair enough, but honestly, seems a very simple approach given the requirements. Doesn't seem any more complex that writing azure functions to start processes, does the timeout on azure functions not limit this approach?
    Last edited by woohoo; 30 September 2019, 18:09.

    Leave a comment:


  • minestrone
    replied
    Originally posted by woohoo View Post
    My first thought would be to write a windows service and have it spawn multiple threads that connect to each source. I would then have a config table with the source details and if disabled or not.
    I've written pretty much this exact system, although it was java threads and CORBA waiting on multiple other systems connecting.

    It was about 15 years ago though and I wouldn't even entertain that kind of architecture now. If pushed and as said I would be more inclined to fire off new processes as at least they are viewable on the OS.

    Leave a comment:


  • minestrone
    replied
    I'm not sure I find the idea of hosting a server that takes HTTP commands to open ports that appealing.

    Leave a comment:


  • Freewill
    replied
    I think I would embed an HTTP server inside the app running on a specific port, and then when you want to update the configuration you could just POST commands to it using curl.

    If you're feeling a bit more fancy you could serve up a static index.html page with some inputs and a button which posts the right commands for you. You would access this page using your browser at e.g. http://localhost:9000/index.html

    And if you're feeling even more fancy than that then you could build a complete React app and serve it up.

    I haven't used it but something like this might be suitable: GitHub - unosquare/embedio: A tiny, cross-platform, module based web server for .NET
    Last edited by Freewill; 27 September 2019, 18:29.

    Leave a comment:


  • woohoo
    replied
    Originally posted by d000hg View Post
    My current understanding is that first of all this is all raw TCP/IP, you build a message byte-by-byte in a very exact way and then send it over ethernet. This message says "I want to receive a datastream". The remote device then will start tossing data at you each time something of interest happens; as mentioned above it's not clear if the connection remains open and I haven't done this low-level stuff for a long time - but it IS pretty low level. I believe the underlying hardware is really working over serial interface, etc, with an ethernet adapter (can't go into any more details for NDA etc).
    Right get yer.

    So my guess is create a tcp listener server that runs on the server (console app or win service etc). In an infinite loop just have the server listening for a tcp connection and spawn a thread to handle that connection.

    As you said have another thread running to check config file or table, whatever then kill the relevant thread. Though, if the thread dealing with the connection is going to update a DB, don't know why you cant check config table and end the thread.

    Leave a comment:


  • CheeseSlice
    replied
    Originally posted by d000hg View Post
    My current understanding is that first of all this is all raw TCP/IP, you build a message byte-by-byte in a very exact way and then send it over ethernet. This message says "I want to receive a datastream". The remote device then will start tossing data at you each time something of interest happens; as mentioned above it's not clear if the connection remains open and I haven't done this low-level stuff for a long time - but it IS pretty low level. I believe the underlying hardware is really working over serial interface, etc, with an ethernet adapter (can't go into any more details for NDA etc).
    To deal with that low level stuff, have a look at IoT gateways. Device sits at the remote location talking RS232 or whatever, and forwards telemetry etc onto the IoT hub,... if you were considering that architecture.
    All of this of course depends on how many devices (a few, thousands?), what you need to do with the data, what capabilities you want, etc, etc.

    Leave a comment:

Working...
X