SMTP போர்ட்டுக்கு அஞ்சலை அனுப்பும் அம்சம் – ஒரு பயனர் கொடுத்த அற்புதமான யோசனை
பயனர் கணினியின் SMTP போர்ட்டுக்கு அஞ்சலை அனுப்புவதற்காக ஹாரி ஹோச்ஹெய்சர் (Harry Hochheiser) தனது துண்டு நிரலை எனக்கு அனுப்பியதுதான் திட்டத்தில் உண்மையான திருப்புமுனையாக அமைந்தது. இந்த அம்சத்தை நம்பகமான முறையில் செயல்படுத்தினால், மற்ற எல்லா அஞ்சல் கொண்டு சேர்க்கும் முறைகளும் வழக்கற்றுப் போய்விடும் என்பதை நான் உடனடியாக உணர்ந்தேன்.
பல வாரங்களாக நான் ஃபெட்ச்மெயிலை கொஞ்சம் கொஞ்சமாக மேம்பாடு செய்து கொண்டிருந்தேன். அதே நேரத்தில் இடைமுக வடிவமைப்பு வேலை செய்யக்கூடியதாக இருந்தது, ஆனால் நேர்த்தியாக இல்லை. மற்றும் பல அபத்தமான விருப்பமைவுகளுடன் இருந்தது. கொண்டு வந்த அஞ்சலை அஞ்சல் பெட்டிக் கோப்பு (mailbox file) அல்லது நிலையான வெளியீட்டிற்கு (standard output) அனுப்புவதற்கான விருப்பங்கள் என்னை மிகவும் தொந்தரவு செய்தன, ஆனால் ஏன் என்று எனக்குப் புரியவில்லை.
(இணைய அஞ்சலின் விவரமான தொழில்நுட்பத்தில் உங்களுக்கு நாட்டம் இல்லாவிட்டால், அடுத்த இரண்டு பத்திகளைத் தவிர்க்கலாம்.)
SMTP மேலனுப்புதல் பற்றி யோசித்தபோது நான் பார்த்தது என்னவென்றால், பாப்க்ளையன்ட் பல வேலைகளைச் செய்ய முயற்சி செய்கிறது. இது ஒரு அஞ்சல் போக்குவரத்து முகவராகவும் (mail transport agent – MTA) மற்றும் அஞ்சல் விநியோக முகவராகவும் (mail delivery agent – MDA) வடிவமைக்கப்பட்டுள்ளது. SMTP மேலனுப்புதல் மூலம், அது MDA வேலையைத் தவிர்த்து ஒரு தூய MTA ஆக இருக்கலாம். செண்ட்மெயில் (sendmail) செய்வது போலவே உள்ளூர் வினியோகத்திற்கு மற்ற செயலிகளுக்கு அஞ்சலைக் கொடுத்து விடலாம்.
TCP/IP ஆதரவுள்ள எந்த இயங்குதளத்திலும் போர்ட் 25 இருக்கும் என கிட்டத்தட்ட உத்தரவாதம் அளிக்கப்பட்டிருக்கும் போது, அஞ்சல் விநியோக முகவரை உள்ளமைப்பது அல்லது அஞ்சல் பெட்டியைப் பூட்டிவிட்டு பின்னிணைப்பு செய்வது போன்ற அனைத்து சிக்கல்களையும் ஏன் இழுத்துப் போட்டுக் கொள்ள வேண்டும்? குறிப்பாக, கொண்டு வந்த அஞ்சல் சாதாரண அனுப்புநர்-தொடங்கிய SMTP அஞ்சலைப் போல் இருக்கும் என்று உத்தரவாதம் அளிக்கப்படும்போது. இதுதானே நாம் உண்மையில் விரும்புவது.
(மீண்டும் உயர் நிலைக்கு….)
லினஸின் முறைகளை மனப்பூர்வமாகப் பின்பற்ற முயற்சித்ததன் மூலம் நான் பெற்ற மிகப்பெரிய பலன்
ஃபெட்ச்மெயில் பதிவிறக்க பக்கம்
முந்தைய தொழில்நுட்பச் சொற்கள் உங்களுக்குப் புரியாவிட்டாலும், இங்கு பல முக்கியமான பாடங்கள் உள்ளன. முதலாவதாக, இந்த SMTP-மேலனுப்புதல் கருத்து லினஸின் முறைகளை மனப்பூர்வமாகப் பின்பற்ற முயற்சித்ததன் மூலம் நான் பெற்ற மிகப்பெரிய ஒற்றைப் பலன் ஆகும். ஒரு பயனர் எனக்கு இந்த அற்புதமான யோசனையை வழங்கினார். நான் செய்ய வேண்டியதெல்லாம் அதன் தாக்கங்களைப் புரிந்துகொள்வதுதான்.
மணிமொழி 11. உங்களுக்கு நல்ல யோசனைகள் தோன்றுவதற்கு அடுத்து சிறந்தது உங்கள் பயனர்களின் நல்ல யோசனைகளை அடையாளம் காண்பதே. சில நேரங்களில் பிந்தையதே மேலும் சிறந்தது.
நீங்கள் உண்மையிலேயே அடக்கமாக இருந்தால், கண்டுபிடிப்பை நீங்களே செய்தீர்கள் என உலகம் முழுவதும் நினைப்பார்கள்
சுவாரசியமாக, மற்றவர்களுக்கு எவ்வளவு கடன்பட்டிருக்கிறீர்கள் என்பதில் நீங்கள் முழுமையாக உண்மையிலேயே அடக்கமாகவும் இருந்தால், கண்டுபிடிப்பின் ஒவ்வொரு பகுதியையும் நீங்களே செய்தீர்கள் எனவும் உங்கள் உள்ளார்ந்த மேதையைப் பற்றி அடக்கமாக இருக்கிறீர்கள் எனவும் உலகம் முழுவதும் நினைப்பார்கள். லினஸுக்கு இது எவ்வளவு நன்றாக வேலை செய்தது என்பதை நாம் அனைவரும் பார்க்கலாம்!
(ஆகஸ்ட் 1997 இல் நடந்த முதல் பெர்ல் (Perl) மாநாட்டில் நான் எனது உரையை நிகழ்த்தியபோது, அபாரமான கொந்தர் லாரி வால் (Larry Wall – பெர்ல் நிரல் மொழி உருவாக்கியவர்) முன் வரிசையில் இருந்தார். மேலே கடைசி வரிக்கு வந்ததும், அவர் சமயப் போதனை பாணியில், “சொல்லுங்கள், சொல்லுங்கள், சகோதரரே!” என்றார். பார்வையாளர்கள் அனைவரும் சிரித்தனர். ஏனென்றால் இது பெர்ல் நிரல் மொழி கண்டுபிடிப்பாளருக்கும் வேலை செய்தது என்பது அவர்களுக்குத் தெரியும்.)
சில வாரங்களுக்குப் பிறகு அதே உற்சாகத்தில் திட்டத்தை இயக்கிய பிறகு, எனது பயனர்களிடமிருந்து மட்டுமல்ல, இதைக் கேள்விப்பட்ட மற்றவர்களிடமிருந்தும் இதே போன்ற பாராட்டுகளைப் பெற ஆரம்பித்தேன். அந்த மின்னஞ்சலில் சிலவற்றை சேமித்து வைத்துள்ளேன். எப்போதாவது என் வாழ்க்கை பயனுள்ளதா என்று நான் யோசிக்க ஆரம்பித்தால் அதை எடுத்து மீண்டும் பார்ப்பேன் :-).
இதுநாள்வரைத் தவறான சிக்கலைத் தீர்க்க முயற்சித்து வந்திருக்கிறேன்
ஆனால் எல்லா வகையான வடிவமைப்பிற்கும் பொதுவான இரண்டு அடிப்படையான, அரசியல் அல்லாத பாடங்கள் இங்கே உள்ளன.
மணிமொழி 12. பல நேரங்களில், பிரச்சினை இன்னது என்ற உங்கள் கருத்து தவறானது என்பதை உணரத் தொடங்குவதில் இருந்தே மிகவும் குறிப்பிடத்தக்க மற்றும் புதுமையான தீர்வுகள் உருவாகின்றன.
அனைத்து வகையான அறைகுறை உள்ளூர் விநியோக முறைகளுடன் ஒருங்கிணைந்த MTA/MDA வாக பாப்கிளையண்டைத் தொடர்ந்து உருவாக்குவதன் மூலம் தவறான சிக்கலைத் தீர்க்க முயற்சித்து வந்திருக்கிறேன். ஃபெட்ச்மெயிலின் வடிவமைப்பானது சாதாரண SMTP-பேசும் இணைய அஞ்சல் பாதையின் ஒரு பகுதியான ஒரு தூய MTA என அடிப்படையிலிருந்து மறுபரிசீலனை செய்யப்பட வேண்டும்.
வளர்ச்சியில் நீங்கள் ஒரு சுவர் போன்ற தடையில் முட்டி நிற்கும் போது – அடுத்த ஒட்டு நிரலைத் தாண்டிச் சிந்திக்க உங்களுக்குக் கடினமாக இருக்கும்போது – உங்களுக்குச் சரியான பதில் கிடைத்ததா என்று கேட்காமல், சரியான கேள்வியைத்தான் கேட்கிறீர்களா என்று பார்க்க வேண்டிய நேரம் இது. ஒருவேளை பிரச்சினையையே மாற்றியமைக்க வேண்டியிருக்கலாம்.
செயல்திறனை இழக்காமல் செய்ய முடிந்தால், பயனற்ற பழைய அம்சங்களை நீக்கத் தயங்காதீர்கள்
ஆகவே, நான் என் பிரச்சினையை மாற்றியமைத்தேன். தெளிவாக, செய்ய வேண்டியது இதுதான் (1) SMTP மேலனுப்புதல் ஆதரவைப் பொதுவான இயக்கியில் (generic driver) மாற்றி எழுதுவது, (2) அதை இயல்புநிலை பயன்முறையாக மாற்றுவது மற்றும் (3) இறுதியில் மற்ற எல்லா கொண்டு சேர்க்கும் முறைகளையும், குறிப்பாக கோப்பில் கொண்டு சேர் (deliver-to-file) மற்றும் நிலையான வெளியீட்டில் கொண்டு சேர் (deliver-to-standard-output) ஆகியவற்றை நீக்குவது.
நான் மூன்றாம் படியைப் பற்றிக் கொஞ்ச காலம் தயங்கினேன். மாற்று கொண்டு சேர்க்கும் வழிமுறைகளைச் சார்ந்திருக்கும் நீண்ட கால பாப்கிளையன்ட் பயனர்களை எரிச்சல்படுத்தப் பயந்தேன். கோட்பாட்டின்படி, அதே விளைவுகளைப் பெற அவர்கள் உடனடியாக .forward கோப்புகள் அல்லது சமமான செண்ட்மெயில் அல்லாத அஞ்சல்களுக்கு மாறலாம். ஆனால் நடைமுறையில் இந்த மாற்றம் குழப்பமாக இருக்கக்கூடும்.
ஆனால் நான் அதைச் செய்தபோது, பலன்கள் மிகப் பெரிதாக இருந்தன. இயக்கி நிரலின் மிக மோசமான பகுதிகள் மறைந்துவிட்டன. உள்ளமைவு அடியோடு எளிமையாகிவிட்டது. திட்டத்தின் MDA மற்றும் பயனரின் அஞ்சல்பெட்டி கிடைக்குமா என்று அலைய வேண்டாம், கோப்பு பூட்டுதலை இயங்குதளம் ஆதரிக்கிறதா என்பதைப் பற்றியும் கவலைப்பட வேண்டாம்.
மேலும், அஞ்சலை இழக்கக்கூடிய ஒரே வழியும் மறைந்துவிட்டது. நீங்கள் ஒரு கோப்பிற்குக் கொண்டு சேர்க்கக் குறிப்பிட்டு, வட்டு (disk) நிரம்பியிருந்தால், உங்கள் அஞ்சல் தொலைந்துவிடும். SMTP மேலனுப்புதலில் அஞ்சல் தொலைந்து போகாது. ஏனெனில் செய்தியைக் கொண்டு சேர்க்க முடியாவிட்டால் அல்லது குறைந்த பட்சம் பின்னர் கொண்டு சேர்ப்பதற்காக சுருட்டி வைக்காவிட்டால் (spooled) உங்கள் SMTP கேட்குநர் (listener) OK அனுப்பாது.
மேலும் செயல்திறன் மேம்பட்டது (ஒரே ஓட்டத்தில் உங்களுக்குத் தெரியவராது என்றாலும்). இந்த மாற்றத்தின் மற்றொரு முக்கிய நன்மை என்னவென்றால், கையேடு மிகவும் எளிமையாகிவிட்டது.
பின்னர், இயங்குநிலை SLIP சம்பந்தப்பட்ட சில தெளிவற்ற சூழ்நிலைகளைக் கையாள அனுமதிப்பதற்காக, பயனர் குறிப்பிட்ட உள்ளூர் MDA மூலம் கொண்டுசேர்த்தலை மீண்டும் கொண்டு வர வேண்டியிருந்தது. ஆனால் நான் அதைச் செய்வதற்கான ஓர் எளிய வழியைக் கண்டுபிடித்தேன்.
இதன்மூலம் நாம் கற்க வேண்டிய பாடம் என்ன? செயல்திறனை இழக்காமல் உங்களால் செய்ய முடியும் என்றால், பயனற்றுப்போன பழைய அம்சங்களைத் தூக்கி எறியத் தயங்காதீர்கள். அன்டோயின் டி செயின்ட்-எக்சூபெரி (Antoine de Saint-Exupéry – அவர் புகழ்பெற்ற குழந்தைகள் புத்தகங்களை எழுதாத போது விமானியாகவும் விமான வடிவமைப்பாளராகவும் இருந்தார்) கூறினார்:
மணிமொழி 13. “(வடிவமைப்பில்) முழுமை அடைவது என்பது சேர்ப்பதற்கு எதுவும் இல்லாதபோது அல்ல, மாறாக நீக்குவதற்கு எதுவும் இல்லாதபோதுதான்.”
உங்கள் நிரல் சிறப்பாகவும் எளிமையாகவும் இருக்கும் போது, அது சரியானது என்று உங்களுக்குத் தெரியவரும். இவ்வாறாக, ஃபெட்ச்மெயில் வடிவமைப்பு அதன் முன்னோர் பாப்கிளையன்டிலிருந்து வேறுபட்ட தன் சொந்த அடையாளத்தைப் பெற்றது.
ஆகவே பெயர் மாற்றும் நேரம் வந்துவிட்டது. புதிய வடிவமைப்பு பழைய பாப்கிளையன்டை விட செண்ட்மெயிலின் இரட்டையர் போன்றது. இரண்டும் MTA க்கள், ஆனால் செண்ட்மெயில் தள்ளிக் கொண்டுசேர்க்கிறது, புதிய பாப்கிளையன்ட் இழுத்துக் கொண்டுசேர்க்கிறது. எனவே, தொடங்கி இரண்டே மாதங்களில், நான் அதை ஃபெட்ச்மெயில் (fetchmail) என மறுபெயரிட்டேன்.
வழுத்திருத்தம் போல மேம்பாடும் வடிவமைப்பும் கூட இணையாக செய்யக்கூடியவையே (parallelizable)
SMTP கொண்டுசேர்ப்பது எப்படி ஃபெட்ச்மெயிலுக்கு வந்தது என்பது பற்றிய ஒரு பொதுவான பாடம் இக்கதையில் உள்ளது. வழுத்திருத்தம் மட்டும்தான் இணையாக செய்யக்கூடியது (parallelizable) என்று இல்லை, மேம்பாடு மற்றும் (ஒருவேளை ஆச்சரியப்படும் அளவிற்கு) வடிவமைப்பு வகைகளைப் புத்தாய்வு செய்வதும் கூட. உங்கள் மேம்பாடு பாங்கு விரைவான மறுசெய்கை (rapidly iterative) ஆகும்போது, நிரலாக்கம் மற்றும் மேம்பாடு வழுத்திருத்தத்தின் சிறப்பு நிகழ்வுகளாக மாறக்கூடும். அதாவது மென்பொருளின் அசல் திறன்கள் அல்லது கருத்தாக்கத்தில் `வழுக்களை’ சரிசெய்தல்.
வடிவமைப்பின் உயர் மட்டத்தில் இருந்தாலும், உங்கள் தயாரிப்புக்கு அருகில் உள்ள வடிவமைப்பு இடங்கள் வழியாக ஏராளமான இணை-நிரலாளர்கள் சீரற்ற முறையில் நடப்பது (random-walking through the design space) மிகவும் மதிப்புமிக்கதாக இருக்கும். ஒரு குட்டை நீர் எப்படி வடிகாலைக் கண்டுபிடிக்கிறது என்பதைக் கவனியுங்கள். அல்லது எறும்புகள் எப்படி உணவைக் கண்டுபிடிக்கின்றன என்பதைச் சிந்தித்துப் பாருங்கள். அடிப்படையில் பரவல் மூலம் ஆராய்தல் (exploration essentially by diffusion), அதைத் தொடர்ந்து பெரிதாக்கவல்ல தகவல் தொடர்பு உதவியுடன் வளங்களைப் பயன்படுத்துதல் (exploitation mediated by a scalable communication mechanism). ஹாரி ஹோச்ஹெய்சர் (Harry Hochheiser) மற்றும் என்னைப் போலவே இது நன்றாக வேலை செய்கிறது. நீங்கள் நுண்ணிய விவரங்களைப் பார்ப்பதற்காக மிக அருகில் இருந்தீர்கள் என்றால் வெளியிலுள்ளவர்களில் ஒருவர் ஒட்டுமொத்தமாகப் பார்த்து அருகிலேயே ஒரு பெரிய வெற்றியைக் காணக்கூடும்.
மூலநூல்: The Cathedral and the Bazaar by Eric S. Raymond – version 3.0
தமிழாக்கம்: இரா. அசோகன் ashokramach@gmail.com
நன்றி
இத்தொடரில் அடுத்த கட்டுரை: ஃபெட்ச்மெயில் முதிர்ச்சி அடைகிறது
பிறரின் நல்ல யோசனைகளை அவர்களே எதிர்பார்த்ததற்கு மேல் எடுத்துச் செல்லும் பொறியியல் திறன். ஒவ்வொரு கொந்தரும் தங்கள் வாழ்நாளில் சாதிக்க முயலும் வெற்றியைப் போன்றே முடிவுகள் இருந்தன. உண்மையிலேயே ஒரு சிறந்த கருவி நீங்கள் எதிர்பார்க்காத வகையிலும் பயன்தரவேண்டும்.