Comment by Marco Alka on "How to improve the following architecture about communication between multiple devices ?"

While Peter already demonstrated a few alternatives for data transfer (of which a TCP/IP socket connection would be my preferred one), I want to talk about the architecture, because I see the possibility for a little improvement there.

Let me sum up the data flow:

Teacher inputs data into mobile app
Data is sent to server
Data is sent to Pi
All students register fingerprints
Data is sent to server

I don't understand, why you would send all data to the Pi. I would keep data handling central on the server. I would add a button to the app which puts the server into a "await fingerprint for student X" mode, so then the student could put their finger on the reader and the Pi would only send the fingerprint data to the server. Other than that mode of operation, there would be the "take attendance" mode, which makes the server await fingerprints it then matches to the database.

That way, the Pi doesn't need to be able to handle data at all. It just sends a fingerprint (which makes things easy on that limited hardware). Since everything is done centrally, extending the functionality only requires you to change the server code (and maybe a bit of GUI in the app), but you keep concerns separated, which is nice.

Thank you.

I put my question exactly for improving the architecture.

The reason behind that architecture, When pi take fingerprints of students it should know who is the teacher, what class , what he teach etc this settings are configured by the teacher in android application and sent to the server now.If I don't send the data to raspberry then I can't know those fingerprint belong to which class.That's why I said it's better to send both information from raspberry.

Thank you for the suggestions I will try use them.

Kareem The Pi doesn't need to know anything about the class or teacher. Only the server needs to know those things, as it is the central instance. In order to pair the fingerprint with the data, just tell the server that it will receive a fingerprint for a certain student next and it will be able to update the data with the next fingerprint it receives.

Except you plan to scale that solution to many FP readers, which should work in parallel. Then you would also need to tell the server from which reader it should expect a certain input.

By the way: the more FP readers, app users and modi you have, the more it makes sense to implement an Entity-Component-System on the server.

Thank you so much for the reply.

I finally understand completely what did you say.

First when I thought of this architecture I knew something wasn't correct that's why I asked here.

So like you said mobile application sends the data to server then the server if he gets any request then he check which FP reader send it then check FP and return the result. Easy and can be done by RESTful only.

About the architecture I will read about it in details.

Thank you again.

Search Hashnode