Software architecture [indy?]

[Tntman 14]

Hi, I need to make app for my final assignment . In this topic i would like to talk with you about concepts/techniques that i plan to use.. I would like to hear your suggestions and ideas ( will you change something in this design etc... )

 

Here is description:

We have 2 applications. Mobile and desktop.

 

Mobile ( Android only ) 

Have to be able to scan QR Code 

i planed to use this LIB -> https://github.com/Spelt/ZXing.Delphi

Have ability to display scanned data in memo for example. 

Save scanned data in txt file on android device.

 

On the left side of program is list of all  txt files that are saved in folder and on the right side is list of all other clients ( PC's with app on them ) 

user is checking file on the left and client ( PC ) on the right and he is sending that text file to PC. Reason why i am sending file to PC is that PC's are connected to printers and it is easier to manipulate with the document on PC( change from txt to pdf,word,excel etc ) and print it.

 

So is Indy component set good for this task? I was thinking to use Indy TCP client and indy tcp server for sending user list ( user list is list of all pcs that are running application ) and for sending txt file i would probably use Indy FTP.. 

So, to explain little bit more. When user open android app he will receive list of all pcs that are currently running app. When user on android checks file and client ( PC ) from the list he is sending txt file to pc. I only need to send files one way from Android -> pc.

 

Desktop app will serve as file receiver and as i said i will probably add some functionality to manipulate with txt files.

 

Also, people should be able to communicate even if internet is off. What I mean by "internet is off" .. Well imagine that in school we have one router and we cut down internet but people would be still be able to connect on "router" and network, so when people connect on that "router"/network will they be able to communicate and exchange data over that network with indy ? <- i think that answer is YES, i performed little tests but i would like to hear your confirmation

 

Also i was googling yesterday and i found this components called "app thethering" -> 

 

I have not researched them yet but it looks like that they could also be used for similar purpose of exchanging data and files...

 

Thank you for your suggestions and answers

 

 

Edited May 4, 2020 by Tntman

[Fr0sT.Brutal 900]

Why inventing custom solutions (in TCP you'll have to develop whole protocol and FTP is very old and likely will become obsolete in several years) and using 3rd party components when you have full-featured HTTP with system-native HTTP request component.

[Tntman 14]

1 hour ago, Fr0sT.Brutal said:

Why inventing custom solutions (in TCP you'll have to develop whole protocol and FTP is very old and likely will become obsolete in several years) and using 3rd party components when you have full-featured HTTP with system-native HTTP request component.

I dont think i need to invent custom protocol , i think that there are available send recive/stream in indy tcp...

 

Reason why i mentioned FTP is his name ( file transfer protocol ) so it was logical to me to use that in this indy combination.. I know that we could send streams over indy TCP so basically i could send file over indy tcp but i wanted FTP because it is more logical to me it is higher lvl than tcp so it works on top of it .. But still i am open for your suggestions..

 

Im not sure in HTTP request components, i think that my concept is more suitable for indy tcp .. tcp is lower level than HTTP so how can it become obsolete in several years? Also im not sure why u say that FTP will be forgiven in few years , can you elaborate more on that?

 

And can you elaborate more on http requests, what do u mean exactly ? 

 

Maybe i was not clear in first post but when i say "PC" i am referring to school laptops that are used by staff that is working there. So there is no MAIN "PC" that will gather and collect all information, whole group ( array ) of "PCs" is dynamic, some professors/staff members are connecting some are disconnecting + other ones are connecting on their phones so everything is dynamic like a chat room basically..

 

 

Edited May 4, 2020 by Tntman

[Fr0sT.Brutal 900]

Okay let's go deeper. You intend to use custom TCP. So you have to implement both sides (client & server) of it, develop message format, likely including auth & encryption, different request types (get list, put file, ...) and so on. Of course that's possible and not that hard but seem useless in your case.

6 minutes ago, Tntman said:

tcp is lower level than HTTP so how can it become obsolete in several years? Also im not sure why u say that FTP will be forgiven in few years , can you elaborate more on that?

Sure TCP won't go away I was talking on FTP only. Well, it has some design problems (two channels f.ex.) and for some reason more and more servers drop it in favor of HTTP.

HTTP is implemented with system-native components which means you won't bother with custom SSL libs and it's pretty powerful protocol that is able to do all things you want.

12 minutes ago, Tntman said:

Maybe i was not clear in first post but when i say "PC" i am referring to school laptops that are used by staff that is working there. So there is no one "PC" that will gather and collect all information, whole group ( array ) of "PCs" is dynamic, some professors/staff members are connecting some are disconnecting + other ones are connecting on their phones so everything is dynamic like a chat room basically..

If you mean completely serverless solution then probably any TCP-based protocol won't fit your needs, maybe you'll need UDP multicasting.

[Tntman 14]

 

1 hour ago, Fr0sT.Brutal said:

You intend to use custom TCP. So you have to implement both sides (client & server) of it,

There is indy tcp client and indy tcp server , planed to use them

 

1 hour ago, Fr0sT.Brutal said:

develop message format

for message format i planned to use simple json something like this :

[
   command:"ListOfAllComputers"
	{
		professor: "ProfesorName",
		classrom: "NumberOfClassrom",
                socketID: "socketIDGoesHere"
	},
	{
		professor: "ProfesorName", 
                classrom: "NumberOfClassrom",
                socketID: "socketIDGoesHere"
	},
]

So in my mobile app if command = ListOfallComputers i loop over json object and display it in listview for example.. i can receive that "command" and whole data in indy tcp server onExecute event or in indy tcp client by checking if buffer is empty..

 

When I want to send file , I will choose file and select professor name from the list. Behind the scenes i will grab socketId from certain professor and send file to it.

 

On professor PC i have built in events ( indy tcp server ) onExecute and on id tcp client side there is some function to check buffer is empty "IdTCPClient.IOHandler.InputBufferIsEmpty" <- im not sure if this is how it is actually called because I dont have rad studio opened now..

So if buffer is not empty and command = downloadFileFromMobile my desktop program will accept that file and save it .. Thats some logic, basically i think that in theory i could use both ( indy tcp server and indy tcp client ) because there is no actual main SERVER ( any device can be server or client ).... maybe I am wrong but I already tried to make simple text exchange with indy tcp client and indy tcp server components and it worked

 

 

 

 

1 hour ago, Fr0sT.Brutal said:

likely including auth & encryption, different request types (get list, put file, ...) and so on.

There will not be auth or encryption i will not use SSL , whole app is proof of concept ( in the end i could hard code some values in source code that will be used for auth <- i know what this is not the right way , just saying )

1 hour ago, Fr0sT.Brutal said:

Sure TCP won't go away I was talking on FTP only

Sorry my bad

 

1 hour ago, Fr0sT.Brutal said:

maybe you'll need UDP multicasting

Never planned to use UDP as it seems to be much harder and i actually never heard of UDP multicasting , i will try to read more about it

 

 

Edited May 4, 2020 by Tntman

[Remy Lebeau 1396]

9 hours ago, Tntman said:

There is indy tcp client and indy tcp server , planed to use them

The point was, if you use the plain vanilla TCP client/server components, then you have to design your own protocol on top of them, and implement both sides of that protocol.  If you use a standard protocol, like FTP or HTTP, then you don't need to implement both sides (unless you really need to customize both sides), you can use pre-existing implementations.  And HTTP has benefits over FTP.

9 hours ago, Tntman said:

On professor PC i have built in events ( indy tcp server ) onExecute and on id tcp client side there is some function to check buffer is empty "IdTCPClient.IOHandler.InputBufferIsEmpty" <- im not sure if this is how it is actually called because I dont have rad studio opened now..

"check buffer is empty" is not a good way to approach this task in the first place.

[Tntman 14]

14 hours ago, Remy Lebeau said:

The point was, if you use the plain vanilla TCP client/server components, then you have to design your own protocol on top of them, and implement both sides of that protocol.  If you use a standard protocol, like FTP or HTTP, then you don't need to implement both sides (unless you really need to customize both sides), you can use pre-existing implementations.  And HTTP has benefits over FTP.

I got it now, problem is that i dont have idea how could i use http with this

 

14 hours ago, Remy Lebeau said:

"check buffer is empty" is not a good way to approach this task in the first place.

In my little demo that I made i was using this as a reference -> https://stackoverflow.com/questions/22838159/indy-tidtcpclient-receive-text  -> first demo without thread and with timer...

 

i just remodeled a little bit using IdThreadCommand instead of timer -> event OnRun -> 

 if IdTCPClient.IOHandler.InputBufferIsEmpty then
  begin
    IdTCPClient.IOHandler.CheckForDataOnSource(10);
    if IdTCPClient.IOHandler.InputBufferIsEmpty then exit;
  end;

 

 

[Remy Lebeau 1396]

7 hours ago, Tntman said:

In my little demo that I made i was using this as a reference -> https://stackoverflow.com/questions/22838159/indy-tidtcpclient-receive-text  -> first demo without thread and with timer...

That kind of "check for empty buffer" logic makes sense in a UI timer, to prevent blockage of the UI.  It makes less sense to use that kind of logic in a worker thread, as demonstrated in that same post.