[c++]FTP client maken

[jos707]

Ik werk dagelijks op een mainframe waar bestanden worden opgeladen, meestal
zijn dit gewoon tekstbestanden. Nu gebruik momenteel gewoon ftp commandos
in een dos-venster om deze bestanden af te halen en te kunnen raadplegen.
Een beetje omslachtig dus om telkens aan te loggen op de mainframe met user/pass
en dan met het get commando het bestand af te halen.
Nu zou ik hiervoor gewoon een programma willen maken dat ik kan gebruiken om
deze bestanden af te halen van de mainframe en die deze ook opent om de inhoud
te tonen. Alleen vraag ik mij af hoe ik hieraan moet beginnen ik ga gewoon voor mijn gui
win32 of mfc gebruiken maar dan? Is er zoiets als een gratis FTP SDK dat ik kan
gebruiken of kan ik beter alle FTP calls zelf programmeren ?

[whoami]

Ik denk dat je hier wel wat verder mee kunt:
klik

[TheBlasphemer]

Voor zover ik weet is er geen FTP API/SDK, Maar het FTP protocol is ook niet bijster moeilijk.
Voor GUI kun je zelf kiezen, Win32, MFC, TCL/TK, you name it, is compleet jouw keuze
Voor sockets in C:
http://beej.us/guide/bgnet/

FTP protocol:
http://www.google.co.uk/s...start=0&ie=utf-8&oe=utf-8

[Obliterator]

Waarom niet gewoon een windows FTP client. Met bijvoorbeeld Total commander kan ik ook tekstfiles op een ftp server heel simpel en snel openen met de interne tekst viewer.

Gezien je het over een dos-venster hebt ga ik er vanuit dat je onder windows werkt.

[ Voor 21% gewijzigd door Obliterator op 01-02-2006 21:19 ]

[MBV]

Je kan ervoor kiezen om een OSS FTP-client te pakken, en er je eigen GUI voor te schrijven. Alleen denk ik dat het lastig is om het bestaande aanbod op te leuken met wat 'nieuws'

[NMe]

offtopic:
Zou je het invoegen van harde enters misschien achterwege kunnen laten? Ik zie dat je eigenlijk in bijna al je posts zelf enters invoert, terwijl het forum die uitlijning prima zelf kan regelen. Dit leest wel vervelend zo.

[El Cid]

jos707 schreef op woensdag 01 februari 2006 @ 21:10:
Ik werk dagelijks op een mainframe waar bestanden worden opgeladen, meestal
zijn dit gewoon tekstbestanden. Nu gebruik momenteel gewoon ftp commandos
in een dos-venster om deze bestanden af te halen en te kunnen raadplegen.
Een beetje omslachtig dus om telkens aan te loggen op de mainframe met user/pass
en dan met het get commando het bestand af te halen.
Nu zou ik hiervoor gewoon een programma willen maken dat ik kan gebruiken om
deze bestanden af te halen van de mainframe en die deze ook opent om de inhoud
te tonen. Alleen vraag ik mij af hoe ik hieraan moet beginnen ik ga gewoon voor mijn gui
win32 of mfc gebruiken maar dan? Is er zoiets als een gratis FTP SDK dat ik kan
gebruiken of kan ik beter alle FTP calls zelf programmeren ?

Mischien is VIM iets voor je? Daarmee kun je bestanden rechtstreeks via FTP benaderen.

[Soultaker]

Je zou iets als cURL kunnen gebruiken. (In deze inleiding staat bijvoorbeeld ook wat over uploaden naar FTP.)

[jos707]

Thx voor de reacties. Het feit dat ik dit zelf wil schrijven in plaats van een standaard ftp programma zoals LeechFTP,WS_FTP,.. is natuurlijk om het zelf te kunnen aanpassen aan mijn wensen. Zo zijn er bepaalde bestanden die ik bijvoorbeeld niet wil zien en deze kan ik dan filteren enzo.
Het uploaden van bestanden zal ik niet gebruiken het gaat meer een om het raadplegen en in mindere mate het downloaden van bestanden.

Maar ik begrijp dat ik dus met sockets aan de slag zal moeten, hier heb eigenlijk nog geen ervaring mee en ga dus bovenstaande linkjes nader onderzoeken.

[Verwijderd]

Kijk eens naar UltraEdit of een andere geavanceerde teksteditor, die bieden je namelijk de mogelijkheid om files direct vanaf een FTP site te bewerken. Ideaal voor een snelle tekstwijziging en handiger dan even een FTP protocol implementeren Voor Linux zijn er ongetwijfeld alternatieven, volgens mij kent bijv. Emacs ook dergelijke functionaliteit.

[farlane]

midnight commander ftw

[Verwijderd]

Anders kan je FileZilla eens bekijken. Dit is een zeer goeie open source ftp client. Ik vermoed dat hij geschreven is in C++ dus je aanpassingen moeten geen probleem zijn.

[jos707]

Ik ben ondertussen al een beetje verder, heb ondertussen al een klein gui in elkaar gezet met wxWidgets (had teveel slechte ervaringen gelezen over mfc).

Het is dus de bedoeling dat ik bestanden op de mainframe(TSO) kan oplijsten of kan downloaden naar de lokale schijf. Dit werkt perfect in een DOS-box met het dir,ls of get commando.
Nu heb ik geprobeerd bij wijze van test dit eens te doen in een echte ftp-applicatie zoals Smart-ftp. Het connecten naar de mainframe lukt zonder problemen maar wanneer ik in de commandline een dir of ls commando ingeef krijg ik steeds de error 500 Command unrecognized. Deze error krijg ik ook in andere ftp-applicaties zoals Total Commander.

Waarom lukt dit in een DOS wel met bv. het commando: dir 'datasetX.in.*' ?

[curry684]

jos707 schreef op maandag 06 februari 2006 @ 14:45:
Ik ben ondertussen al een beetje verder, heb ondertussen al een klein gui in elkaar gezet met wxWidgets (had teveel slechte ervaringen gelezen over mfc).

offtopic:
MFC is dan ook al jaren deprecated en wordt sinds iets van 1998 niet meer ontwikkeld.

Win32 heeft overigens gewoon een FTP-SDK of zoiets. Het heet WinInet, is standaard aanwezig sinds Win2k, en biedt functies aan als FtpCreateDirectory, FtpGetFile e.d. Werkt perfect, staat asynchrone transfers toe etc. Documentatie vind je op MSDN as usual.

Dat daargelaten overigens vind ik het een klassiek gevalletje 'wrong tool for the right job' om dit in C++ te gaan maken. In C# heb je dit in een paar uur basaal gebouwd inclusief GUI.

[ Voor 9% gewijzigd door curry684 op 06-02-2006 16:23 ]

[.oisyn]

curry684 schreef op maandag 06 februari 2006 @ 16:21:
Dat daargelaten overigens vind ik het een klassiek gevalletje 'wrong tool for the right job' om dit in C++ te gaan maken. In C# heb je dit in een paar uur basaal gebouwd inclusief GUI.

Je bedoelt dat de win32 API the wrong tool is, het ligt natuurlijk niet aan C++ dat het zoveel langer moet duren en ook voor C++ zijn er RAD tools te verkrijgen (nou heb ik niet zoveel ervaring met VCL zoals je weet, maar het lijkt me dat het daarmee niet veel langer hoeft te duren).

Desnoods zou je C++ nog icm .Net interop kunnen gebruiken

[ Voor 17% gewijzigd door .oisyn op 06-02-2006 16:26 ]

[_js_]

Omdat de dos ftp client dat voor jou vertaalt naar LIST

Probeer maar eens "lit dir" of "lit ls", dan krijgt de ftp server echt die opdracht, en krijg je dezelfde foutmelding.

met "lit help" of "remotehelp" krijg je een lijst met ondersteunde opdrachten van de ftp server zelf.

[remco_k]

curry684 schreef op maandag 06 februari 2006 @ 16:21:
[...]

offtopic:
MFC is dan ook al jaren deprecated en wordt sinds iets van 1998 niet meer ontwikkeld.

Win32 heeft overigens gewoon een FTP-SDK of zoiets. Het heet WinInet, is standaard aanwezig sinds Win2k, en biedt functies aan als FtpCreateDirectory, FtpGetFile e.d. Werkt perfect, staat asynchrone transfers toe etc. Documentatie vind je op MSDN as usual.

Dat daargelaten overigens vind ik het een klassiek gevalletje 'wrong tool for the right job' om dit in C++ te gaan maken. In C# heb je dit in een paar uur basaal gebouwd inclusief GUI.

In C++ ook als je daar al in thuis bent.
Voor de TS: Kijk even naar Indy, zij bieden een hele zooi open source IP tools waaronder FTP clients:
http://www.indyproject.org/

[curry684]

.oisyn schreef op maandag 06 februari 2006 @ 16:25:
[...]

Je bedoelt dat de win32 API the wrong tool is, het ligt natuurlijk niet aan C++ dat het zoveel langer moet duren en ook voor C++ zijn er RAD tools te verkrijgen (nou heb ik niet zoveel ervaring met VCL zoals je weet, maar het lijkt me dat het daarmee niet veel langer hoeft te duren).

Nee klopt, tis met name Win32 die hier dwarszit, maar dan nog zou ik (als projectmanager) voor een tool van dit niveau het foutgevoeligheidsrisico van C++ niet nemen tegenover een beschermendere taal dan C# die in dit geval minimaal net zo performant uit de hoek gaat komen. Beetje klassiek geval met een voorhamer een mier aanvallen

[jos707]

Ja ik begrijp dat het misschien in C# sneller zou kunnen maar ik ken helemaal niets van C#, en om even een kompleet nieuwe taal te gaan leren vooraleer ik aan het werk kan is ook een beetje te gek.
Dus heb ik gewoon wxWidgets gebruikt omdat ik geen beter alternatief vond in combinatie met c++. Misschien is Borland vcl wel een alternatief maar ik heb dus alleen visualc++ voorhanden.

Nu om even op het eerste probleem terug te komen: wanneer ik nu in een ftp programma :
list 'datasetx.in.*' doe krijg ik de error 426 : Data tranfer aborted, terwijl wanneer ik dit in een dos venster doe gewoon een lijst krijg van alle bestand die in zich in datadset 'datasetx.in.' bevinden.
Om eerlijk te zijn ken ik niet echt veel van mainframes maar ik veronderstel dat deze zich gewoon gedraagd als een ftp server waar bestanden of datasets staan dus waarom doet die het in dos maar niet in een ftp client?
Stel dat dit niet werk in een ftp client heeft het natuurlijk geen zin dat ik mijn eigen ftp client prog en moet ik dus gewoon in dos blijven hakelen om aan mijn bestanden te kunnen

[farlane]

curry684 schreef op maandag 06 februari 2006 @ 16:30:
Beetje klassiek geval met een voorhamer een mier aanvallen

Als keuzes voor een taal alleen op performance gebaseerd zouden zijn wel. Er zijn natuurlijk nog vele andere overwegingen die de keuze op een andere taal zou doen uitkomen.

[curry684]

farlane schreef op dinsdag 07 februari 2006 @ 08:44:
[...]

Als keuzes voor een taal alleen op performance gebaseerd zouden zijn wel. Er zijn natuurlijk nog vele andere overwegingen die de keuze op een andere taal zou doen uitkomen.

Typische andere overwegingen die ik aangeef quote je dan ook wel heel gericht niet in deze post

[Verwijderd]

gaat allemaal eenvoudig met QT: GUI maken is zeer makkelijk en heeft een eigen ftp-klasse: http://doc.trolltech.com/4.0/qftp.html

er is nu trouwens ook voor windows een (gratis) open source-versie.

[jos707]

De gratis versie van QT voor windows is een oudere versie, om de nieuwste versie te kunnen
gebruiken moet je alsnog een licentie betalen.

Nu lijkt mij wxWindows evenwaardig met QT dus heb niet echt een reden om over te schakelen.
Ik heb nu ook een module wxFTP die samen met wxWindows kan worden gebruikt dus ga ik mij
hier verder in verdiepen.

[.oisyn]

En het feit dat je je code door Qt's preprocessor moet halen is natuurlijk ook nogal lame, aangezien het probleem (signals en slots) prima in puur C++ is op te lossen

[MBV]

offtopic:
@.iosyn: ze hebben een en ander zelf geïmplementeerd, omdat ten tijde van ontwikkeling er nog maar heel weinig standard compliant compilers waren. Sterker nog: volgens mij moest 'de standaard' nog uitgevonden worden. Ook nu nog zijn de compilers op sommige ondersteunde platformen om te huilen. Nu zijn er nettere manieren (bijv standaard datastructuren gebruiken ipv eigen brouwsels), maar dat wordt nog lang niet overal ondersteund. Vraag maar aan de Mozilla-crew, welke delen van de C-standaard niet gebruikt mogen worden .
@jos707: oudere versie? Ik zie gewoon 4.1 in de GPL versie.
Ik hoor graag waarom Qt niet goed is, maar volgens mij zijn dit verkeerde argumenten.

[.oisyn]

MBV schreef op woensdag 08 februari 2006 @ 16:13:
@.iosyn: ze hebben een en ander zelf geïmplementeerd, omdat ten tijde van ontwikkeling er nog maar heel weinig standard compliant compilers waren. Sterker nog: volgens mij moest 'de standaard' nog uitgevonden worden. Ook nu nog zijn de compilers op sommige ondersteunde platformen om te huilen. Nu zijn er nettere manieren (bijv standaard datastructuren gebruiken ipv eigen brouwsels), maar dat wordt nog lang niet overal ondersteund. Vraag maar aan de Mozilla-crew, welke delen van de C-standaard niet gebruikt mogen worden .

offtopic:
Waarom gebruik je altijd die totaal onleesbare offtopic tag?

Sorry hoor, maar de C++ standaard bestaat al bijna 8 jaar, wat een eeuwigheid is in IT. En Qt 3.0 kwam pas in 2001, toen die standaard al wat breder bruikbaar was. Dus hadden ze, zeker voor versie 4.0, wel gebruik kunnen maken van de standaard features van C++ (en dat hoeven nog niet eens partial template specializations te zijn, met simpele member function pointers ben je er al, en iedereen ondersteunt dat). En kijk bijvoorbeeld eens naar boost::signals, werkt ook op een hele rits compilers.

Het probleem is natuurlijk ook niet zozeer die preprocessor zelf. Goed, het is een extra stap die je moet doen, maar niet onoverkomelijk. Het probleem zit 'm in het feit dat IDEs en code refacturers geen reet snappen van Qt's syntax. Het is gewoon geen C++, dus het kan ook niet door een C++ parser, met alle gevolgen van dien (maar goed, die linuxhippies kloppen hun code natuurlijk nog altijd in een algemene texteditor dat draait in een standaard tekstscherm, dus die hebben er sowieso geen last van ). Ik vind het wat ver gaan om bij voorbaat alle devtools die mensen mogelijk kunnen gebruiken bij hun dagelijkse werk te negeren door lekker je eigen taaltje te ontwerpen.

.edit: en compatibiliteit met oude code is natuurlijk geen issue. Zorg dat je in een nieuwe versie aan de standaard voldoet, en lever een preprocessor mee die je oude source omzet naar de standaard C++ syntax. Oude code breekt niet, en nieuwe code kan zonder preprocessor met een conformant compiler gecompileerd worden.

[ Voor 22% gewijzigd door .oisyn op 08-02-2006 17:00 ]

[Verwijderd]

Ik vind dat de voordelen van qt (api met enorm veel mogelijkheden, goed gedocumenteerd en makkelijk te gebruiken) genoeg zijn om de preprocessor even te doen vergeten. De plugin van visual studio werkt vrij goed waardoor je nauwelijks merkt dat er nog een stap tussen zit, weet niet hoe het zit met andere (minder bekende) ide's. Verder lijkt me dat nog steeds een betere oplossing dan even zelf met sockets beginnen en het (alhoewel eenvoudig) ftp-protocol gaan implementeren. Of wat nog werd voorgesteld: code bekijken van open source ftp-programma's. Beide oplossingen gaan te veel werk vergen terwijl het met qftp (of in't geval van de originele poster, de ftp-klasse van wxWindows) veel makkelijker kan en je dus van een neventaak geen hoofdtaak gaat maken.

[.oisyn]

Als het om de FTP API gaat zijn er natuurlijk wel meer opties dan alleen Qt. Bij windows zelf zit bijvoorbeeld al een vrij eenvoudig te gebruiken WinInet API (is al duur curry aangehaald) waarmee je ook met FTP sites kunt verbinden, zonder moeilijk te gaan doen met sockets. Je kunt in principe een hele file binnenhalen met 3 regels code.

[ Voor 5% gewijzigd door .oisyn op 08-02-2006 19:42 ]

[MBV]

@.oisyn: ik gebruik offtopic-tags als iets erg zwaar offtopic is, logisch toch? En in mijn post-history van 2500 posts komen erg weinig offtopic tags tegen volgens mij

Ik vind inderdaad dat ze met Qt 4.0 wat meer standaard dingen hadden moeten gebruiken, maar om daar nou prioriteit van te maken vind ik overdreven. Hoe goed ontworpen de toolkit ook is, het is een legacy applicatie, waarbij je geen idee hebt hoe gebruikers functies hebben misbruikt.
Wat jij voorstelt met een converter is trouwens heel simpel: je converteert het dus eigenlijk op een andere manier. Signal/slot wordt nu ook door moc omgezet naar legale C++ code, dus als jij een generieke manier vindt om dat te doen, kan je je eigen moc maken die dat doet. Juist omdat het zo simpel lijkt zal er een addertje onder het gras zitten: ik vermoed dat de werking nét dat beetje anders is...

offtopic:
zo beter?

[Sendy]

Dat gewone ftp clients het niet goed doen (behalve de zeer eenvoudige) komt omdat de meeste clients kennis hebben over het filesystem, en dan doen data sets (op een IBM mainframe) nogal vreemd aan.

Wat ik kan aanraden is je problemen op te lossen met wat scripting. Neem een goede, scriptbare ftp client (die van Windows XP is ook scriptbaar trouwens). Gebruik deze client om data sets te listen, op te halen. Misschien in verschillende sessies als dat handig blijkt te zijn.

[Tjoekbezoer]

Ikzelf gebruik Netdrive om FTP sites als een harde schijf te mappen, super handig. Linux kan dit uit zichzelf, windows heeft een programma er voor nodig. En het mooie is, Netdrive is gratis!

[jos707]

Sendy schreef op donderdag 09 februari 2006 @ 00:19:
Dat gewone ftp clients het niet goed doen (behalve de zeer eenvoudige) komt omdat de meeste clients kennis hebben over het filesystem, en dan doen data sets (op een IBM mainframe) nogal vreemd aan.

Wat ik kan aanraden is je problemen op te lossen met wat scripting. Neem een goede, scriptbare ftp client (die van Windows XP is ook scriptbaar trouwens). Gebruik deze client om data sets te listen, op te halen. Misschien in verschillende sessies als dat handig blijkt te zijn.

Ik heb het ondertussen wel voor elkaar gekregen om mijn datasets op te lijsten.
Blijkbaar verstaat de ftp server op een IBM mainframe met het MVS besturingssysteem geen ftp commandos zoals LIST of NLST, maar wanneer ik het commando STAT dataset.x.* krijg ik een string terug met de gervraagde datasets. Nu zal ik dus deze string moeten parsen om mooi een lijstje te krijgen van al mijn bestanden. Ik weet niet of dit de beste manier is maar op deze manier werkt het dus wel. En dit met de ingebouwde api wxFTP in wxWindows dus ik heb geen exotische ftp API's nodig om het werkende te krijgen.

[.oisyn]

MBV schreef op woensdag 08 februari 2006 @ 23:57:
@.oisyn: ik gebruik offtopic-tags als iets erg zwaar offtopic is, logisch toch? En in mijn post-history van 2500 posts komen erg weinig offtopic tags tegen volgens mij

offtopic:
Het viel me gewoon op

Wat jij voorstelt met een converter is trouwens heel simpel: je converteert het dus eigenlijk op een andere manier. Signal/slot wordt nu ook door moc omgezet naar legale C++ code, dus als jij een generieke manier vindt om dat te doen, kan je je eigen moc maken die dat doet. Juist omdat het zo simpel lijkt zal er een addertje onder het gras zitten: ik vermoed dat de werking nét dat beetje anders is...

Mijn punt was nou juist dat je geen converter wilt hebben, maar gewoon pure standaard C++ code wilt schrijven, zodat al je mogelijke devtools (IDE's, doc generators, code completion plugins, ...) het ook gewoon snappen . Begrijp me niet verkeerd, ik vind dat ze in het verleden zeker een punt hadden, maar tegenwoordig is dat toch wel een beetje achterhaald. En tegenwoordig hebben die devtools ook nog eens een veel prominentere plaats dan vroeger.

VC++ 2003 icm Visual Assist snapt er bijvoorbeeld al niets van:

offtopic:
zo beter?

Ik probeerde niets voor te schrijven overigens

[MBV]

.oisyn schreef op donderdag 09 februari 2006 @ 13:21:
[...]

offtopic:
Het viel me gewoon op

offtopic:
In een FTP-topic een holy war uitvechten over QT vind ik dan ook erg offtopic

[...]

Mijn punt was nou juist dat je geen converter wilt hebben, maar gewoon pure standaard C++ code wilt schrijven, zodat al je mogelijke devtools (IDE's, doc generators, code completion plugins, ...) het ook gewoon snappen . Begrijp me niet verkeerd, ik vind dat ze in het verleden zeker een punt hadden, maar tegenwoordig is dat toch wel een beetje achterhaald. En tegenwoordig hebben die devtools ook nog eens een veel prominentere plaats dan vroeger.

VC++ 2003 icm Visual Assist snapt er bijvoorbeeld al niets van:
[afbeelding]

Point taken. Ach, dan gooi je het toch door moc heen? Daarna is het wel legale C++ code. Je wilt alleen niet weten hoe dat eruit ziet... .
Ik durf aardig wat te wedden dat heel wat mensen bij QT er ook niet blij meer mee zijn. Ben wel blij voor een hele berg bedrijven dat ze niet zeggen: "ga al je signals en slots maar opnieuw schrijven", aangezien het STL-gedrag ongetwijfeld anders zal zijn dan het QT gedrag. Ook durf ik er heel wat om te verwedden dat er meerdere compilers nog steeds dwars liggen. hun site laat o.a. AIX en HP-UX zien. Ik weet niet hoe de huidige versies zijn, maar ik heb daar nogal op horen schelden tijdens mijn stage

[...]


Ik probeerde niets voor te schrijven overigens

Jaja, zeg je nu

[.oisyn]

MBV schreef op donderdag 09 februari 2006 @ 15:22:
Ben wel blij voor een hele berg bedrijven dat ze niet zeggen: "ga al je signals en slots maar opnieuw schrijven", aangezien het STL-gedrag ongetwijfeld anders zal zijn dan het QT gedrag.

boost::signals zit nog niet in de STL, maar ik bedoelde dat ze zelf een (vergelijkbare) implementatie kunnen maken in pure C++ code. En voor de mensen die oude code hebben is zo'n converter nou juist weer wel handig: je vervangt de oude convertor door een nieuwe convertor die de oude code preprocessed naar de nieuwe syntax. Zodat oude code niet breekt, en nieuwe code gewoon zonder convertor geschreven kan worden.

Ook durf ik er heel wat om te verwedden dat er meerdere compilers nog steeds dwars liggen. hun site laat o.a. AIX en HP-UX zien.

Tja, compiler / library bugs hou je altijd. Ik heb even een kijkje genomen en geen van de bugs die ze aanhalen hebben ook maar iets met ISO C++ compliance te maken

[MBV]

OK, ik snap nu wat je bedoelt. Als je het zelf maakt, is het idd mogelijk om het gedrag gelijk te houden. Ook ga je (waarschijnlijk) naar het randje van de C++-spec, en ga je dus weer ruzie krijgen met compilers. Van Trolltech kunnen ze het nog beter uitleggen dan ik: http://doc.trolltech.com/4.1/templates.html. Over waarom geen STL maar Qt klassen gebruiken hebben ze in een whitepaper het een en ander gezegd, in hoofdstuk 15.

Over die pagina die ik liet zien: dat zijn dus problemen die je nu, na conflict-mijdend gedrag, nog over zijn. Daarbij maken ze geen gebruik van de STL. Het is geen lijst van dingen die ze moesten vermijden, die zou véél te groot worden