Ad-hoc network using TCP

  • Thread starter Thread starter zainab
  • Start date Start date
Z

zainab

Hello;

I'm having some problems connecting two devices (a laptop and a pda)
via ad-hoc using TCP. What disturbs me more is that the same code works
if i use it in the same computer (via localhost). The client always
thinks he's connecting to the server and the server never assumes to be
connected to any client (just keeps waiting).

Here are both codes:

SERVER:

IPEndPoint localEndPoint=new IPEndPoint("192.168.0.20", 8001);
Socket newsock=new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.TCP);
newsock.Bind(localEndPoint);
newsock.Listen(200);
Socket s=newsock.Accept(); // keeps waiting here
<rest of code>

also tried:

TcpListener myListener=new TcpListener(IPAddress.Parse("192.168.0.20",
8001);
myListener.Start();
Socket s=myListener.AcceptSocket(); // waits here


CLIENT:
TcpClient tcpclnt = new TcpClient();
tcpclnt.Connect("192.168.0.20", 8001); // jumps this code as if
connected, no notice on server
<rest of code>

the client's ip is 192.168.1.20. they work under UDP, but i can't get
them to work on TCP.

HELP!
tks
 
well, nevermind, seemed to be an IP problem....
changed the 192.168.1.20 to 192.168.0.2 and it worked...
 
Can't say that I've done much, other than implement some of the
OpenNETCF.Net support (such as it was in SDF 1.4), and test it a little,
with ad hoc. I see a few things that I'd do differently:

Server:

1. I don't see any reason to bind the socket to a particular IP address.
Why don't you pass IPAddress.Any as the first parameter to your IPEndPoint
constructor?

2. I'd set the ProtocolType to either Unspecified or IP, not TCP.

3. Listen( 200 ) is a *very* large backlog number for a little mobile
device. 5 would be more reasonable, in my book.

Client:

4. What's the subnet mask of these addresses? They're statically-assigned,
not DHCP, right?

Can you make the code work on a normal, either wired or wireless
infrastructure mode, network? Ad hoc just complicates things and, for me,
I'd try to get it working on the simplest-to-use network and then move to ad
hoc and try to get it working.

Paul T.
 
Both devices have to be on the same subnet. So, mask each IP with the
subnet mask of the device and those values *must* match. For example:

device #1 IP = 192.168.0.20, subnet mask = 255.255.255.0

result = 192.168.0.0 is the subnet.

device #2 IP = 192.168.1.20, subnet mask = 255.255.255.0

result = 192.168.1.0 is the subnet

Since these two devices have *different* subnets, they can only communicate
if there is a router between them (and they must both have the IP address of
that router, as it faces them), set properly in their configurations. They
cannot communicate directly with each other. Because of the zeroes in one
of your subnets, communication, at least partial might be mistakenly thought
to be occurring.

You could also have changed the subnet masks on *both* devices to
255.255.0.0 and that would have worked, too (the masked subnet for both
devices, in that case, would have still been 192.168.0.0, allowing them to
talk to each other).

Paul T.
 
Hello!
thanks for the replies!
yes, it was a subnet mask problem. it was indeed 255.255.0.0 and with a
set gateway. i had no idea as the pda isn't mine and i was using the
used settings for the udp, that worked (silly me for not thinking of
this eariler), but it works correctly now.

About the previous reply:

1. I don't see any reason to bind the socket to a particular IP
address.
Why don't you pass IPAddress.Any as the first parameter to your
IPEndPoint
constructor?
Yes, i'll do this after (it was set to this as i was minimizing the
chances for it not to go anyway wrong, so everything was as specific as
possible).

2. I'd set the ProtocolType to either Unspecified or IP, not TCP.
I'll try, but i dont know the exact difference. I thought since i
wanted TCP, TCP it is.

3. Listen( 200 ) is a *very* large backlog number for a little mobile
device. 5 would be more reasonable, in my book.
There are plenty mobile devices, not just one, but yes, 200 is too
large!

Client:

4. What's the subnet mask of these addresses? They're
statically-assigned,
not DHCP, right?
Yes, static, and obtained in run time (via Dns.GetHostName.AdressList)

Can you make the code work on a normal, either wired or wireless
infrastructure mode, network? Ad hoc just complicates things and, for
me,
I'd try to get it working on the simplest-to-use network and then move
to ad
hoc and try to get it working.
It really has to be ad-hoc... the mobile devices connect to a local
gateway that has a sensor network linked to it and then info is
broadcasted via tcp/udp (depending on the data being sent) to the
mobile devices.
While testing, i'll just use localhost and two win32 apps. If not just
for speed, as the connection establishing on pda<->pc is taking 8-10
seconds...

Thanks again!


Paul G. Tobey [eMVP] escreveu:
 
2. You're reading more into "TCP" than is really there. Set it to
Unspecified or IP.

3. I wouldn't set it to 300 for a PC-based server, let alone a small server
on the Pocket PC...

4. I understand that the *goal* is ad hoc, but trying to do everything at
once is almost always a bad idea. That's why you build and download and try
your application several times during its development, rather than trying to
code the entire application before ever trying it! Remember that localhost
doesn't necessarily *do* any real network I/O, also...

Paul T.


zainab said:
Hello!
thanks for the replies!
yes, it was a subnet mask problem. it was indeed 255.255.0.0 and with a
set gateway. i had no idea as the pda isn't mine and i was using the
used settings for the udp, that worked (silly me for not thinking of
this eariler), but it works correctly now.

About the previous reply:

1. I don't see any reason to bind the socket to a particular IP
address.
Why don't you pass IPAddress.Any as the first parameter to your
IPEndPoint
constructor?
Yes, i'll do this after (it was set to this as i was minimizing the
chances for it not to go anyway wrong, so everything was as specific as
possible).

2. I'd set the ProtocolType to either Unspecified or IP, not TCP.
I'll try, but i dont know the exact difference. I thought since i
wanted TCP, TCP it is.

3. Listen( 200 ) is a *very* large backlog number for a little mobile
device. 5 would be more reasonable, in my book.
There are plenty mobile devices, not just one, but yes, 200 is too
large!

Client:

4. What's the subnet mask of these addresses? They're
statically-assigned,
not DHCP, right?
Yes, static, and obtained in run time (via Dns.GetHostName.AdressList)

Can you make the code work on a normal, either wired or wireless
infrastructure mode, network? Ad hoc just complicates things and, for
me,
I'd try to get it working on the simplest-to-use network and then move
to ad
hoc and try to get it working.
It really has to be ad-hoc... the mobile devices connect to a local
gateway that has a sensor network linked to it and then info is
broadcasted via tcp/udp (depending on the data being sent) to the
mobile devices.
While testing, i'll just use localhost and two win32 apps. If not just
for speed, as the connection establishing on pda<->pc is taking 8-10
seconds...

Thanks again!


Paul G. Tobey [eMVP] escreveu:
Both devices have to be on the same subnet. So, mask each IP with the
subnet mask of the device and those values *must* match. For example:

device #1 IP = 192.168.0.20, subnet mask = 255.255.255.0

result = 192.168.0.0 is the subnet.

device #2 IP = 192.168.1.20, subnet mask = 255.255.255.0

result = 192.168.1.0 is the subnet

Since these two devices have *different* subnets, they can only
communicate
if there is a router between them (and they must both have the IP address
of
that router, as it faces them), set properly in their configurations.
They
cannot communicate directly with each other. Because of the zeroes in
one
of your subnets, communication, at least partial might be mistakenly
thought
to be occurring.

You could also have changed the subnet masks on *both* devices to
255.255.0.0 and that would have worked, too (the masked subnet for both
devices, in that case, would have still been 192.168.0.0, allowing them
to
talk to each other).

Paul T.
Click to expand...
Click to expand...
 
Again, tks!

The server is a pc, it's the "clients" that are the handheld devices.
I have the sensor network and the udp communications already working
correctly, so i'm just playing with TCP now on w32 apps (since i now
made sure it works by the "air"). It'll be basically sending text files
around.


Paul G. Tobey [eMVP] escreveu:
2. You're reading more into "TCP" than is really there. Set it to
Unspecified or IP.

3. I wouldn't set it to 300 for a PC-based server, let alone a small server
on the Pocket PC...

4. I understand that the *goal* is ad hoc, but trying to do everything at
once is almost always a bad idea. That's why you build and download and try
your application several times during its development, rather than trying to
code the entire application before ever trying it! Remember that localhost
doesn't necessarily *do* any real network I/O, also...

Paul T.


zainab said:
Hello!
thanks for the replies!
yes, it was a subnet mask problem. it was indeed 255.255.0.0 and with a
set gateway. i had no idea as the pda isn't mine and i was using the
used settings for the udp, that worked (silly me for not thinking of
this eariler), but it works correctly now.

About the previous reply:

1. I don't see any reason to bind the socket to a particular IP
address.
Why don't you pass IPAddress.Any as the first parameter to your
IPEndPoint
constructor?
Yes, i'll do this after (it was set to this as i was minimizing the
chances for it not to go anyway wrong, so everything was as specific as
possible).

2. I'd set the ProtocolType to either Unspecified or IP, not TCP.
I'll try, but i dont know the exact difference. I thought since i
wanted TCP, TCP it is.

3. Listen( 200 ) is a *very* large backlog number for a little mobile
device. 5 would be more reasonable, in my book.
There are plenty mobile devices, not just one, but yes, 200 is too
large!

Client:

4. What's the subnet mask of these addresses? They're
statically-assigned,
not DHCP, right?
Yes, static, and obtained in run time (via Dns.GetHostName.AdressList)

Can you make the code work on a normal, either wired or wireless
infrastructure mode, network? Ad hoc just complicates things and, for
me,
I'd try to get it working on the simplest-to-use network and then move
to ad
hoc and try to get it working.
It really has to be ad-hoc... the mobile devices connect to a local
gateway that has a sensor network linked to it and then info is
broadcasted via tcp/udp (depending on the data being sent) to the
mobile devices.
While testing, i'll just use localhost and two win32 apps. If not just
for speed, as the connection establishing on pda<->pc is taking 8-10
seconds...

Thanks again!


Paul G. Tobey [eMVP] escreveu:
Both devices have to be on the same subnet. So, mask each IP with the
subnet mask of the device and those values *must* match. For example:

device #1 IP = 192.168.0.20, subnet mask = 255.255.255.0

result = 192.168.0.0 is the subnet.

device #2 IP = 192.168.1.20, subnet mask = 255.255.255.0

result = 192.168.1.0 is the subnet

Since these two devices have *different* subnets, they can only
communicate
if there is a router between them (and they must both have the IP address
of
that router, as it faces them), set properly in their configurations.
They
cannot communicate directly with each other. Because of the zeroes in
one
of your subnets, communication, at least partial might be mistakenly
thought
to be occurring.

You could also have changed the subnet masks on *both* devices to
255.255.0.0 and that would have worked, too (the masked subnet for both
devices, in that case, would have still been 192.168.0.0, allowing them
to
talk to each other).

Paul T.

well, nevermind, seemed to be an IP problem....
changed the 192.168.1.20 to 192.168.0.2 and it worked...
Click to expand...
Click to expand...
Click to expand...
 
Again, tks!

The server is a pc, it's the "clients" that are the handheld devices.
I have the sensor network and the udp communications already working
correctly, so i'm just playing with TCP now on w32 apps (since i now
made sure it works by the "air"). It'll be basically sending text files

around.
But could u explain me the difference between using a TCPListener and
creating a socket binded to an EndPoint with those TCP/IP settings?
They both work, but i can't choose one over the other cause i don't
really know the differences. I'd prefer one more flexible for when i'll
have to deal with multiple clients and then broadcast info.
tks.

Paul G. Tobey [eMVP] escreveu:
2. You're reading more into "TCP" than is really there. Set it to
Unspecified or IP.

3. I wouldn't set it to 300 for a PC-based server, let alone a small server
on the Pocket PC...

4. I understand that the *goal* is ad hoc, but trying to do everything at
once is almost always a bad idea. That's why you build and download and try
your application several times during its development, rather than trying to
code the entire application before ever trying it! Remember that localhost
doesn't necessarily *do* any real network I/O, also...

Paul T.


zainab said:
Hello!
thanks for the replies!
yes, it was a subnet mask problem. it was indeed 255.255.0.0 and with a
set gateway. i had no idea as the pda isn't mine and i was using the
used settings for the udp, that worked (silly me for not thinking of
this eariler), but it works correctly now.

About the previous reply:

1. I don't see any reason to bind the socket to a particular IP
address.
Why don't you pass IPAddress.Any as the first parameter to your
IPEndPoint
constructor?
Yes, i'll do this after (it was set to this as i was minimizing the
chances for it not to go anyway wrong, so everything was as specific as
possible).

2. I'd set the ProtocolType to either Unspecified or IP, not TCP.
I'll try, but i dont know the exact difference. I thought since i
wanted TCP, TCP it is.

3. Listen( 200 ) is a *very* large backlog number for a little mobile
device. 5 would be more reasonable, in my book.
There are plenty mobile devices, not just one, but yes, 200 is too
large!

Client:

4. What's the subnet mask of these addresses? They're
statically-assigned,
not DHCP, right?
Yes, static, and obtained in run time (via Dns.GetHostName.AdressList)

Can you make the code work on a normal, either wired or wireless
infrastructure mode, network? Ad hoc just complicates things and, for
me,
I'd try to get it working on the simplest-to-use network and then move
to ad
hoc and try to get it working.
It really has to be ad-hoc... the mobile devices connect to a local
gateway that has a sensor network linked to it and then info is
broadcasted via tcp/udp (depending on the data being sent) to the
mobile devices.
While testing, i'll just use localhost and two win32 apps. If not just
for speed, as the connection establishing on pda<->pc is taking 8-10
seconds...

Thanks again!


Paul G. Tobey [eMVP] escreveu:
Both devices have to be on the same subnet. So, mask each IP with the
subnet mask of the device and those values *must* match. For example:

device #1 IP = 192.168.0.20, subnet mask = 255.255.255.0

result = 192.168.0.0 is the subnet.

device #2 IP = 192.168.1.20, subnet mask = 255.255.255.0

result = 192.168.1.0 is the subnet

Since these two devices have *different* subnets, they can only
communicate
if there is a router between them (and they must both have the IP address
of
that router, as it faces them), set properly in their configurations.
They
cannot communicate directly with each other. Because of the zeroes in
one
of your subnets, communication, at least partial might be mistakenly
thought
to be occurring.

You could also have changed the subnet masks on *both* devices to
255.255.0.0 and that would have worked, too (the masked subnet for both
devices, in that case, would have still been 192.168.0.0, allowing them
to
talk to each other).

Paul T.

well, nevermind, seemed to be an IP problem....
changed the 192.168.1.20 to 192.168.0.2 and it worked...
Click to expand...
Click to expand...
Click to expand...
 
Back
Top