Home/ Questions/Q 8106187
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T00:23:27+00:00

I’m writing a server and client system in python. The purpose of the system

  • 0

I’m writing a server and client system in python. The purpose of the system is to check whether or not the clients are online.

The clients will periodically make a request to the central server to “check in”. If the server doesn’t receive that request within the specified time period, it will alert a human.

I’m new to network programming, so I’m not sure which technology would be the most appropriate for what I am trying to do.

I’ve been looking at:

  • Twisted
  • UDP or TCP Sockets
  • HTTP requests

I haven’t made up my mind if the server will reply to the clients’ requests yet. If it did reply, then it would only be to assure the client program that it has been “checked in”. This seems a bit redundant though.

I’m leaning towards a TCP socket server model, because it seems to be the most simple and reliable solution.

So in conclusion, I have two questions:

  1. What is the most appropriate networking technology for my network?
  2. Does it make sense to establish a two way connection? Or should a one way connection from the client to server suffice?

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As i understand it, which is admittedly not well, Twisted is just a framework for implementing protocols with. you could implement http WITH twisted, it is not an alternative TO http.

    for 1:
    If i were doing this, and i didn’t have any concrete requirements, http (or https) would be high on my list. it can make it through any firewall you want to go through without reconfiguration, you’ll have a multitude of toolsets on BOTH ends to work with (server and app development), and it works on everything. it would be easy to just GET ‘http://server.com/checkin?id=12345&status=OK’ or something. just keep in mind that will be visible to outsiders if security is any concern. some sort of time+ID-based token (think public key encrypted string) and https could be used to keep outsiders from using a replay attack. (which might look like: ‘https://server.com/checkin?token=7d71905f039f67bedcaec2fe5ccc6783’ where the hex string would decrypt to ‘$ID:$STATUS:$TIME’ or similar at the server.)

    another benefit of using http would be that ‘checkin’ above could be almost anything on any platform, from java to .net to python, perl, ruby, php, etc. running on any combination of windows, solaris, linux, bsd, or really anything else. it would be simple to load balance (for when you’re making billions having licensed your ‘SuperCheckIn’ app to all the fortune 1000) and would really have no upper limitations and very few lower bounds. the device would enjoy similar freedom of software, as you could use a fancy custom windows service, or “lowly” wget and cron on *nix. (note: nothing against wget or cron there, they’re some of my favorite things)

    if you need superlightweight, like for an arm (or lesser) processor embedded in a device, UDP might be a decent answer, but you’ll have to figure out some way to be more reliable, if check-ins are critical. a simple ACK response with a basic checksum of the data received could work and would be easy to implement.

    having just implemented a UDP server to listen to an ARM device over a cellular network, i have to say, it doesn’t get much simpler than UDP.

    for 2: that really depends on whether you have another method of ensuring the data was transmitted. with UDP, yes, you probably want to acknowledge receipt of the data with a checksum of said data within a specific time period. with http, it’s built in (response codes).

    just remember: KISS. http fulfills that while being inherently compatable. twisted, imho, is a bit complex for the situation.

    • 0