I am trying to develop (on c#) a Point of Sale program(deployed on machine 1), with integrated kitchen display system(deployed on machine 2). I pretty much have an idea how to develop the individual programs, however, I haven't tried integrating thee machines (to function as one) before.

Here's a brief overview of the system im trying to do:

Machine 1 : Point of Sale function - Enter customer orders(do basic POS functions), then PUSH the list of order from the POS to the kitchen display system.

Machine 2 : Kitchen Display System function - Basically what it needs to do is to receive the list of orders pushed by the POS, then queues whenever several tickets were sent at the same time. The KDS bumps a ticket when the order was already prepared. The list queue then moves...and so on.

Machine 3 : Queue System function - when the KDS (kitchen display system) bumps the ticket, the ticket number then displays on the screen. (e.g. serving: 21)

I'm suppose to implement this using one server running on windows XP or later, and three thin clients. Each thin client is equipped with a touch screen display.

I am hoping for your inputs. Thank you very much!!

Dani AI

Generated

As described, the system needs reliable, near–real-time delivery from the POS to two thin clients (KDS and Queue). The simplest working path is a central service that the POS writes to and that broadcasts updates to the KDS and Queue. That can be implemented with (a) simple DB + polling for a proof of concept, (b) a push service using sockets/WCF/HTTP+WebSocket for low latency, or (c) a message broker (durable queue / pub‑sub) for production reliability and loose coupling. pointed to WCF and mentioned a DB approach; both are valid choices depending on required durability, latency, and effort.

Make the message contract explicit and idempotent. A compact JSON payload helps interoperability and debugging:

{
  "OrderId": "GUID-or-int",
  "TicketNumber": 21,
  "Table": "T12",
  "Items": [
    {"ItemId":"i100","Qty":2,"PrepGroup":"grill","Status":"pending"}
  ],
  "CreatedUtc":"2012-01-29T14:40:00Z",
  "IdempotencyKey":"GUID"
}

Important engineering notes not covered earlier in the thread: persist orders first, then publish (outbox pattern) to avoid lost messages; include an IdempotencyKey so re-delivered messages do not create duplicates; require the KDS to acknowledge a message and store the acknowledgement server-side before the Queue display is updated. For "bump" actions, use an atomic update (database transaction or rowversion/optimistic concurrency) to prevent two operators from bumping the same ticket concurrently.

Operational points: keep clocks in sync (NTP), implement exponential backoff and reconnect on thin clients, log delivery/ack events for troubleshooting, and design the KDS UI so state can be rebuilt from persisted order statuses. For a quick POC, DB polling at a short interval works; for production, prefer a durable broker or a push service so the three terminals behave as one reliable system.

Recommended Answers

All 9 Replies

I would recommend posting this question on the MSDN forums, the wait time is shorter for important matters like this. All of the higher knowledge level people on this forum are rarely online. You have people like Thines01, momerath, and ddanbe (not sure if all spelling is correct sorry guys) that are online every other day. So they could answer your question for sure; either way I'd still recommend asking someone over at the MSDN forums because all of their answers are a lot more straight forward (especially considering they have people that are paid to give you programming advice in advanced areas such as this). I hope your problem gets solved soon.

Jamie

Thank you for the advice, Jamie. I'll try my luck over MSDN.

What type of input are you looking for?
Is there a specific question you have about something you've started?
Is there a general question about what technology to use?

hello!

Im trying to weigh my options whether to use 'polling the table', or 'socket programming' in doing the project. what I needed to do is to pass the list of order the POS receives, to the Kitchen Display terminal. I would prefer to have a close to real-time update on the three terminals(POS, KDS, Queue).

Sockets or WCF would probably do the trick.

Have you ever written a client/server app before?

It might be easiest to use a simple database structure, hosted on the server and connected to by the thin clients. Otherwise, as thines mentioned, you might need to design the socket communications from (almost) scratch.

Let's not forget about our friend WCF :)

Thank you for the advice, Jamie. I'll try my luck over MSDN.

It's not a problem; I go there for my more extreme issues. Like I said, Thines01 should be able to help out quite a bit; he helps me with a lot of problems. I'm sorry I can't be of service though. Also I agree with Thines on this, WCF would help.

Any luck with this yet?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.