Recent

Author Topic: Hiring... Maybe..  (Read 18753 times)

aidv

  • Full Member
  • ***
  • Posts: 173
Hiring... Maybe..
« on: September 14, 2015, 05:07:26 am »
Ok so I've been tackling a couple of problems for a while now and I am seriously getting really tired of it and feel really frustrated about it,
so I thought I'd check if it would be possible to get anybody to program for me.

I basically need to transfer files from one device (can be any device, PC, Mac, iPhone, Android etc etc) to another device (specifically an ARM linux computer, much like the raspberry pi.

What I need is the ARM Linux software which should receive files.

If I specify exactly what I need is the actual communication-part.

I don't care if it's bare TCP or HTTP or FTP, as long as it works.
Edit: HTTP would probably be best according to some sources. So the ARM Linux computer would basically be a HTTP server.

Very important note: The receiving have to be memory efficient, so receive in small chunks.

Also the communication HAVE to be 100% correct all of the times.

I also need to be able to send files back to devices.

Can I get away with it for free by someone of you willing to help in person or share some code or library or something or is this a known long/short-term type of project?

I have tried LNet TCP but communication is not always 100% correct.

I am currently trying to use Synapse FTP code, and I just started with it and can't find much info about it.
Edit: actually I'll skip FTP. HTTP seems to be the most logical protocol to use.

If anyone is willing to do it but wants to get paid, how much would you require per hour and how long would it take?

You help me, I help you.

Cheers
« Last Edit: September 14, 2015, 06:36:14 am by aidv »

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Hiring... Maybe..
« Reply #1 on: September 14, 2015, 06:02:30 am »
tbh i don't understand the request.

If your goal is only to send files between those devices, then any of those devices support running an ftp and/or samba client/server.

Or it must be that your goal is to create an application because you want to implement such thing yourself ?

aidv

  • Full Member
  • ***
  • Posts: 173
Re: Hiring... Maybe..
« Reply #2 on: September 14, 2015, 06:27:23 am »
Yes that is correct, Molly.

Any device can support any protocol, but the problem is to make sure that it works.

And also: Yes, I need to implement it myself.

In other words, it has got to be custom software, because everything has to in a controlled manner.

By the way this is for a commercial product so there are specific goals to be achieved.

Thaddy

  • Hero Member
  • *****
  • Posts: 16945
  • Ceterum censeo Trump esse delendam
Re: Hiring... Maybe..
« Reply #3 on: September 14, 2015, 07:24:41 am »
I would be willing to help. Can you contact me by email? If the functional design is well specified I shouldn't have any problems with this type of work. Experienced with synapse on Raspberry Pi and specialized in HP communications for over 25 years. If the device is different from the Pi I will probably need a development device available, either remotely through SSH or on-site. I am only able to work from home in the Netherlands. Some travel is ok with me.
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

aidv

  • Full Member
  • ***
  • Posts: 173
Re: Hiring... Maybe..
« Reply #4 on: September 14, 2015, 03:19:30 pm »
I would be willing to help. Can you contact me by email? If the functional design is well specified I shouldn't have any problems with this type of work. Experienced with synapse on Raspberry Pi and specialized in HP communications for over 25 years. If the device is different from the Pi I will probably need a development device available, either remotely through SSH or on-site. I am only able to work from home in the Netherlands. Some travel is ok with me.

Great! I sent you a PM, please check. Thanks.

jack616

  • Sr. Member
  • ****
  • Posts: 268
Re: Hiring... Maybe..
« Reply #5 on: September 14, 2015, 05:40:38 pm »
"Also the communication HAVE to be 100% correct all of the times."

If that is an accurate statement what you don't want is anything to do with TCP/IP

aidv

  • Full Member
  • ***
  • Posts: 173
Re: Hiring... Maybe..
« Reply #6 on: September 14, 2015, 06:13:31 pm »
"Also the communication HAVE to be 100% correct all of the times."

If that is an accurate statement what you don't want is anything to do with TCP/IP

Well, I have a couple of things to say regarding this.

Firstly, I read about FTP and HTTP and I decided that HTTP would be the best option.

Secondly, HTTP and FTP are all running on top of TCP if I'm not wrong.

Thirdly, what is 100%? For me and you, we would see some flaws and errors, but for the user, it would look like everything is OK because not only can data be sent in chunks, but a chunk could be re-sent if it fails, or the whole file could be re-sent if it fails.
The user would only notice a slight time difference in the transfer process.

Edit:
Foruthly(?), if there are other options and approaches, then by all means, educate me and use whatever fits.

All I care is about the customers at the end of the day.

They are the ones that conciously decide to exchange their hard earned money for a product or a service, so quality and reliability is key.
« Last Edit: September 14, 2015, 06:15:24 pm by aidv »

derek.john.evans

  • Guest
Re: Hiring... Maybe..
« Reply #7 on: September 14, 2015, 06:22:46 pm »
I wrote a HTTP file transfer some time ago for a media server. It was basically a standard HTTP server with 2 extra commands.

A command to get the MD5 of a file, and a command to join any files into one. Both were implemented as GET commands with parameters.

Once I had that, the client could PUT files in any order, or in chunks, validate that all the chunks were transferred correctly via MD5 checks, re-send if required, and then send a command to join the files.

I used Indy, but fp-web should work.

rvk

  • Hero Member
  • *****
  • Posts: 6716
Re: Hiring... Maybe..
« Reply #8 on: September 14, 2015, 06:36:07 pm »
I have tried LNet TCP but communication is not always 100% correct.
Secondly, HTTP and FTP are all running on top of TCP if I'm not wrong.
What would be the upside of doing it with HTTP then... if you say that direct TCP-communication via LNET is not 100% accurate?? In that case HTTP would also not be 100% accurate (HTTP runs on top of TCP). It would all come down to error-control and resending packages. But I think you need to look at the reason why your LNET communication isn't 100% because that could also spell trouble for any other protocol you try.

sam707

  • Guest
Re: Hiring... Maybe..
« Reply #9 on: September 14, 2015, 07:18:33 pm »
communication issues? well i'm using inherited components from TLTcp with lNet packages, never saw errors so far, even on wifi while the box is 35 meters away with 3 large walls in my house.

anyway, it is up to the programmer, in case of, to program a control system.. free pascal has a CRC unit with basic check functions

typical pseudo algorithm :
Code: [Select]
loop:
server sends next chunck/packet
 server computes and sends CRC checksum
 client computes CRC checksum on received data
 client receives CRC checksum from server
 client compares its computed CRC with the one received from server
if equal then // everything went ok
 client says 'ok' to server
 goto loop
else
 client asks server previous data // error occured
 goto loop
« Last Edit: September 14, 2015, 07:50:17 pm by sam707 »

sam707

  • Guest
Re: Hiring... Maybe..
« Reply #10 on: September 14, 2015, 08:24:36 pm »

aidv

  • Full Member
  • ***
  • Posts: 173
Re: Hiring... Maybe..
« Reply #11 on: September 15, 2015, 12:44:57 am »
I wrote a HTTP file transfer some time ago for a media server. It was basically a standard HTTP server with 2 extra commands.

.....


Would you be interested in helping me by sharing some code? Maybe?

I have tried LNet TCP but communication is not always 100% correct.
Secondly, HTTP and FTP are all running on top of TCP if I'm not wrong.
What would be the upside of doing it with HTTP then... if you say that direct TCP-communication via LNET is not 100% accurate?? In that case HTTP would also not be 100% accurate (HTTP runs on top of TCP). It would all come down to error-control and resending packages. But I think you need to look at the reason why your LNET communication isn't 100% because that could also spell trouble for any other protocol you try.


You tell me, I've tried developing my own protocol, doesn't work as expected even though I've done all I can to make it work properly.

communication issues? well i'm using inherited components from TLTcp with lNet packages, never saw errors so far, even on wifi while the box is 35 meters away with 3 large walls in my house.

anyway, it is up to the programmer, in case of, to program a control system.. free pascal has a CRC unit with basic check functions

typical pseudo algorithm :
Code: [Select]
loop:
server sends next chunck/packet
 server computes and sends CRC checksum
 client computes CRC checksum on received data
 client receives CRC checksum from server
 client compares its computed CRC with the one received from server
if equal then // everything went ok
 client says 'ok' to server
 goto loop
else
 client asks server previous data // error occured
 goto loop

That's more or less what I've done except of the CRC part.

I'm still waiting for Thaddy to get back to me since he's willing to help.

Anybody else willing to help?

derek.john.evans

  • Guest
Re: Hiring... Maybe..
« Reply #12 on: September 15, 2015, 01:01:40 am »
I wrote a HTTP file transfer some time ago for a media server. It was basically a standard HTTP server with 2 extra commands.
.....
Would you be interested in helping me by sharing some code? Maybe?

The code was written as a file mirror tool. Or, more importantly, a folder mirror tool. I'm unsure how that fits into your requirements.
Lets say you have a large file to send. What happend's if the server is not available? Is that a situation you need to deal with?

Is folder mirroring something that would suit you? i.e: You save/copy files into a folder, and another process synchronizes the folder with the server?


aidv

  • Full Member
  • ***
  • Posts: 173
Re: Hiring... Maybe..
« Reply #13 on: September 15, 2015, 01:08:38 am »
I wrote a HTTP file transfer some time ago for a media server. It was basically a standard HTTP server with 2 extra commands.
.....
Would you be interested in helping me by sharing some code? Maybe?

The code was written as a file mirror tool. Or, more importantly, a folder mirror tool. I'm unsure how that fits into your requirements.
Lets say you have a large file to send. What happend's if the server is not available? Is that a situation you need to deal with?

Is folder mirroring something that would suit you? i.e: You save/copy files into a folder, and another process synchronizes the folder with the server?

You mean like Google Drive? Then no, that's not what I'm looking for. I just want to programatically send files to the server, I'm just unsure of how to achieve the best results.

derek.john.evans

  • Guest
Re: Hiring... Maybe..
« Reply #14 on: September 15, 2015, 02:02:38 am »
You mean like Google Drive? Then no, that's not what I'm looking for. I just want to programatically send files to the server, I'm just unsure of how to achieve the best results.

Ok, so you are saying you arn't supporting delayed sends.


 

TinyPortal © 2005-2018