0

From my understanding, A TCP session is identified as <ServerIP, ServerPort, ClientIP, ClientPort>.

For instance, the session <192.168.0.1, 80, 192.168.0.2, 1000> is separated from <192.168.0.1, 80, 192.168.0.2, 1001>, and these two sessions can co-exist on the hosts simultaneously.

However, in OPNET, if <192.168.0.1, 80, 192.168.0.2, 1000> is already established, then <192.168.0.1, 80, 192.168.0.2, 1001> cannot be established because port 80 of 192.168.0.1 is already in use.

Given this model, if I try to host a HTTP service on 192.168.0.1:80, there can only be 1 connection to my server at a time, which severely limits the simulation capability.

Please confirm whether the model is indeed problematic, or is there anything I have overlooked. Also a workaround solution would be very appreciated.

314314314
  • 249
  • 1
  • 10
  • It looks like some bug in OPNET. Just check out this question: http://stackoverflow.com/questions/489036/how-does-the-socket-api-accept-function-work – werewindle May 07 '15 at 13:32
  • I too think it is a bug, but what weird is that OPNET is a world class communication network simulation software, I cannot imaging that it would has such a low level bug. – 314314314 May 07 '15 at 13:45
  • What error do you get when trying another connection to server at port 80? – Prabhu May 07 '15 at 19:58
  • The error is "TCP OPEN failed - Port is already in use." – 314314314 May 08 '15 at 05:01

1 Answers1

1

I dug into the source code of OPNET TCP model, and found the bug.

First of all, OPNET does consider <192.168.0.1, 80, 192.168.0.2, 1000> and <192.168.0.1, 80, 192.168.0.2, 1001> as two separate and independent sessions, and it can distinguish them using a session_key.

However, there is a minor bug in the model. When an open request is issued to the TCP model layer (either PASSIVE(listen) or ACTIVE(connect)), the model will check if the local port is being used. If the local port is being used, a error signal will be returned regardless of the type of open request, whereas the correct action is to only check for ACTIVE open.

A solution is to modify the check procedure to only work for ACTIVE open case. Preliminary test shows that multiple connection can be established on the same listening port now.

314314314
  • 249
  • 1
  • 10