lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Changing listen port number on the fly


From: Kieran Mansley
Subject: Re: [lwip-users] Changing listen port number on the fly
Date: Tue, 21 Jun 2011 11:01:07 +0100

On Tue, 2011-06-21 at 11:22 +0200, Enrico Murador - Research &
Development - CET wrote:
> Hi all,
> 
> I'm writing a TCP/UDP server that should allow the user to change the 
> TCP/UDP listening port number,
> but I'm not sure what is the best way to do this. I think I have to 
> close the listening pcb bound to the "old" port number, create a new 
> listen PCB
> and bind the "new" port number to it... 

Sounds OK so far.

> But what I have to do with the 
> already active TCP connections?

That depends on what semantic the user's changing the port number
operation has: 
1) It guarantees that there won't be any connections using the old port
number: you must close the active TCP connections on the old port.
2) It just guarantees that new connections, and the listener, will be on
the new port number: you can just leave the active connections on the
old port number alone and they will carry on working. 

> And if the user "plays around" with port numbers, I think I have to deal 
> with ERR_USE failures on bind() call
> due to listening connections in TIME_WAIT state (for example, if the 
> port number is changed from 1024 to 1025 and then
> re-changed to 1024 without leaving the TIME_WAIT period to elapse).

You always have to handle errors returned by bind(), whether or not
you're changing port numbers.

> Can I use SO_REUSEADDR on listening PCBs without compromising 
> reliability, or it is "safer" to wait?

I think you'll be fine setting SO_REUSEADDR.

> I was thinking if there is a way to change the port that is already 
> bound to a listening TCP pcb, or bound to an UDP pcb,
> without closing the pcb and creating a new one, and if this could 
> "override" the previous problem.

No, there's no such API.

Kieran




reply via email to

[Prev in Thread] Current Thread [Next in Thread]