Roland Kuhn wrote: > Hi Jeff! > It seems like this UDP-based NAT has a lot more problems than I was > aware of. If the firewall were to do NAT based on the RX connections > instead, would that work? What I have in mind is a scheme where a > (potentially large) number of clients are behind a firewall which looks > to a server like a single client with very many open RX connections, all > on port 7001. Are there limitations? Does anybody know of a RX-aware > connection tracking code? > > Ciao, > Roland
RX connections are very short lived. Much shorter than the lifetime of callbacks. You need the server to be able to track a particular client across multiple RX connections including ones established by the server in order that callback breaks can be delivered. The server tracks clients by a combination of source address/port and UUID (if the client supports it). While I could conceive of a way of allowing a firewall to maintain its own RX connection to client mappings, the bigger problem from the perspective of the server is that the server would not be able to effectively distinguish the clients. If two callbacks were requested for the same object by two clients without UUID support, the file server would only record one of them. The callback break would be delivered to one client and not the other. Of course, this is exactly the problem we have today. So adding another layer does not solve anything. The 1.4.1-rc7 file server already has the necessary code to do the right thing as do all 1.4 clients. Now we just have to wait while people upgrade. A slow and painful process but its the only one we have. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
