TCP forward сървърът в действие

Ето какъв изход би могъл да се получи ако при активен TCPForwardServer се свържем към него на порт 2525 и напишем няколко команди към SMTP сървъра:



CODE

1 2 3 4 5 6 7 8 9 10

telnet localhost 2525 220 abv.bg ESMTP HELO 250 abv.bg HELP 214 netqmail home page: http://qmail.org/netqmail QUIT 221 abv.bg Connection to host lost.

Ето и изходът на конзолата на сървъра след изпълнението на горните команди:


CODE

1 2	TCP Forwarding 127.0.0.1:4184 <--> 194.153.145.80:25 started. TCP Forwarding 127.0.0.1:4184 <--> 194.153.145.80:25 stopped.

Няма никаква съществена разлика дали се свързваме директно към mail.abv.bg на порт 25 или към localhost на порт 2525. Това беше и целта на TCP forward сървъра – да осигури прозрачно препращане на някой TCP порт.
Има само един малък проблем. Ако mail.abv.bg по някаква причина не работи вместо да се получи съобщение за отказана връзка:


CODE

1 2	telnet mail.abv.bg 25 Connecting To mail.abv.bg...Could not open connection to the host, on port 25: Connect failed

се осъществява успешно свързване към localhost:2525, след което сокетът се затваря. Правилното поведение би било въобще да се откаже свързване към TCP forward сървъра.
Проблемът идва от това, че нашият сървър винаги приема клиентски заявки независимо дали сървърът е готов и може също да приема клиентски заявки. При по-добрите port forward сървъри нямат такъв дефект, но те обикновено работят на по-ниско ниво. Този дефект може да се преодолее чрез използване на асинхронни сокети, които се поддържат в Java от версия 1.4, но ние няма да се занимаваме с това.


Текстът е подготвен от : Светлин Наков - www.nakov.com