TCP Remote Endpoints
-
Hey guys... I am writing an SMTP server and am interested in adding support for open relay blacklists. However, beyond the implementation, what I need to achieve is retrieving the remote IP from the
TcpClientobject. I know that this can be retrieved from a raw socket object (which can be generated throughTcpListenet.AcceptSocket()as opposed toTcpListener.AcceptTcpClient()), although this doesn't support streaming. Any ideas? Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989 -
Hey guys... I am writing an SMTP server and am interested in adding support for open relay blacklists. However, beyond the implementation, what I need to achieve is retrieving the remote IP from the
TcpClientobject. I know that this can be retrieved from a raw socket object (which can be generated throughTcpListenet.AcceptSocket()as opposed toTcpListener.AcceptTcpClient()), although this doesn't support streaming. Any ideas? Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989You don't want to use TcpListener at all for another even remotely performant. Stick to Socket.Accept(). -- -Blake (com/bcdev/blake)
-
You don't want to use TcpListener at all for another even remotely performant. Stick to Socket.Accept(). -- -Blake (com/bcdev/blake)
Why do you say this? I would have though that something relating to TCP would be best performed by a TcpListener? Is it performance issues, functionality (like what i'm trying to do) or what? Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989
-
Why do you say this? I would have though that something relating to TCP would be best performed by a TcpListener? Is it performance issues, functionality (like what i'm trying to do) or what? Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989
TcpListener is just a wrapper around Socket. It doesn't give enough flexibility for anything but the most simple applications. Certainly not enough to implement an SMTP server. -- -Blake (com/bcdev/blake)
-
TcpListener is just a wrapper around Socket. It doesn't give enough flexibility for anything but the most simple applications. Certainly not enough to implement an SMTP server. -- -Blake (com/bcdev/blake)
Blake Coverett wrote: Certainly not enough to implement an SMTP server. :~ I'll have to debate you on this - the entire serhas has been written and deployed. The only functionality restriction I have discovered was this one problem of determining the remote endpoint. Blake Coverett wrote: It doesn't give enough flexibility for anything but the most simple applications. SMTP, POP3, IMAP and the like are all extremely basic protocols. :doh: For more complex protocol implementations (such as when I implemented the DNS client) I will agree that sockets are more appropriate. Although, I do not value the assosciated coding overheads required to implement the more complex solution when an appropriate wrapper is available. Wrappers are designed to simplfy integration. While I will agree that raw sockets present greater funtionality, I think it is critical that when greater functionality is not required, the appropraite (and probably more reliable) wrapper should be utilised. Anyway, thanks for the help - it certainly spurred some research and did solve the problem. :-D Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989
-
Blake Coverett wrote: Certainly not enough to implement an SMTP server. :~ I'll have to debate you on this - the entire serhas has been written and deployed. The only functionality restriction I have discovered was this one problem of determining the remote endpoint. Blake Coverett wrote: It doesn't give enough flexibility for anything but the most simple applications. SMTP, POP3, IMAP and the like are all extremely basic protocols. :doh: For more complex protocol implementations (such as when I implemented the DNS client) I will agree that sockets are more appropriate. Although, I do not value the assosciated coding overheads required to implement the more complex solution when an appropriate wrapper is available. Wrappers are designed to simplfy integration. While I will agree that raw sockets present greater funtionality, I think it is critical that when greater functionality is not required, the appropraite (and probably more reliable) wrapper should be utilised. Anyway, thanks for the help - it certainly spurred some research and did solve the problem. :-D Tatham Oddie (VB.NET/C#/ASP.NET/VB6/ASP/JavaScript) tatham@e-oddie.com +61 414 275 989
I'm glad to hear the problem is solved. On the merits of TcpListener as a wrapper: If you look through the source for it (isn't Reflector a wonderful tool) you'll see it's all of about 40 lines of code. Really all it does is wrap Bind/Listen in one method and, create TcpClients around accepted sockets, and translate from one set of exceptions to a different set if you try to accept on a closed socket. What does this actually really buy, except hiding the real Socket's based programming model? Perhaps the thought is it buy's having TcpClients rather than sockets after the connect, but they don't add any value in a server scenario at all. The only real abstraction they provide is in the Connect process, which isn't used there. Perhaps what you want is the NetworkStream model for the actual IO. I might argue that too on different grounds, but I won't today. If that's what you want, then then just do a
new NetworkStream(listeningSocket.Accept(), true). Of course, better yet is to use the async Socket.BeginAccept/BeginRead/BeginWrite methods. This is where you'll get scalability. regards, -Blake