Raw TCP/IP library?

[Massimo]

Hi to all

I need to know if there is (inside the main .NET framework or available as a
library) any TCP/IP implementation which can be run over a serial line.

I know the request can sound quite strange, so here are some more elements


I'm testing a client/server application which will be composed of mobile
embedded clients connected to the Internet through GPRS modems and a central
server (written in .NET/C#) which will sit there receiving data from the
clients. The actual clients' CPU will be a mcirocontroller, so their
firmware will be written in plain C language, but for now the actual
hardware isn't available, so I'm just simulating them using standard Windows
program and TCP/IP sockets.

The GPRS modem is a device which can be accessed through a serial port and,
when given proper commands (some proprietary extensions of the AT set),
establishes a GPRS connection, which acts just like a standard modem
connection to an ISP; after doing this, the controlling program needs to run
TCP/IP (PPP) over the "virtual" serial line which is created.

Since I'm testing this modem's behaviour from a Windows application, I need
to go through the whole process of establishing a connection and handling
it; I managed to use Windows to do this by connecting the modem to a
computer, installing a "standard modem" on the same serial port and creating
a DUN connection which, instead of dialing a phone number, just sends the
proper AT commands to establish the GPRS connection; this way, Windows' own
TCP/IP stack is used. Everything works fine.

Now I need to handle this from an application, so I'm in need of a TCP/IP
protocol stack (with PPP!) to run over the GPRS connection, in order to test
the whole process; the actual clients will of course have their own TCP/IP
stack: the microcontrollers I'll use comes with proper C libraries.

I'd like to know if there is anything available for .NET which can run
TCP/IP and PPP over a serial line; if there isn't anything available for
..NET, a standard C library could also do, because I'm anyway going to have
to use one for the final development process, so I can just use it for this
intermediate step and write the simulated clients in C.

Thanks for any suggestion about this strange issue


Massimo

 

[Peter Duniho]

Your original message was excessively crossposted. I've removed the
extraneous, unrelated newsgroups.

As for the actual question:

[...]
The GPRS modem is a device which can be accessed through a serial port
and, when given proper commands (some proprietary extensions of the AT
set), establishes a GPRS connection, which acts just like a standard modem
connection to an ISP; after doing this, the controlling program needs to
run TCP/IP (PPP) over the "virtual" serial line which is created.

So, basically, the GPRS modem works just like any other Dial-Up Networking
modem, except that it uses specifically the GPRS phone network, rather than
being a general-purpose phone modem. Right?

Since I'm testing this modem's behaviour from a Windows application, I
need to go through the whole process of establishing a connection and
handling it; I managed to use Windows to do this by connecting the modem
to a computer, installing a "standard modem" on the same serial port and
creating a DUN connection which, instead of dialing a phone number, just
sends the proper AT commands to establish the GPRS connection; this way,
Windows' own TCP/IP stack is used. Everything works fine.

For the final device, will you actually be writing .NET code to access the
GPRS modem? Or do you simply need to write some kind of .NET code that
*emulates* one of the final devices?

If the latter, I don't see why you need to handle any of the modem
initialization and usage in the .NET code at all. Seems to me, that the
point of the simulation in that case is to test the server, not the client.
If that's the case, then the server doesn't care at all how your client got
onto the network, does it?

Now I need to handle this from an application, so I'm in need of a TCP/IP
protocol stack (with PPP!) to run over the GPRS connection, in order to
test the whole process; the actual clients will of course have their own
TCP/IP stack: the microcontrollers I'll use comes with proper C libraries.

Again, this suggests to me that the test client you're talking about writing
is strictly for use in testing the server, and that the test client code
isn't going to wind up in the final devices at all.

I'd like to know if there is anything available for .NET which can run
TCP/IP and PPP over a serial line; if there isn't anything available for
.NET, a standard C library could also do, because I'm anyway going to have
to use one for the final development process, so I can just use it for
this intermediate step and write the simulated clients in C.

Well, it seems to me that it ought to work just like regular DUN on Windows.
That is, the client code should not care at all about the fact that you're
going through a GPRS modem. You should have the GPRS DUN adapter installed
as part of the Windows network configuration. Then when an Internet
connection is needed (eg your test client code tries to access the server),
Windows can automatically connect the GPRS modem to the Internet.

I don't see why your test client code needs to know anything at all about
GPRS. If you do, perhaps you could explain that part in more detail.

Pete

 

[Massimo]

So, basically, the GPRS modem works just like any other Dial-Up Networking
modem, except that it uses specifically the GPRS phone network, rather
than being a general-purpose phone modem. Right?
Right.

For the final device, will you actually be writing .NET code to access the
GPRS modem? Or do you simply need to write some kind of .NET code that
*emulates* one of the final devices?

The second one.
I don't have (yet) access to the actual hardware, so I'm emulating it with a
Windows application.
I'd like it to actually use the GPRS modem by a serial port.

If the latter, I don't see why you need to handle any of the modem
initialization and usage in the .NET code at all. Seems to me, that the
point of the simulation in that case is to test the server, not the
client. If that's the case, then the server doesn't care at all how your
client got onto the network, does it?

The server doesn't actually care, and in fact I've already tested it.
I need to test the protocol from the client's point of view now... that's
why I need to actually use GPRS. It's a lot more troublesome system than
just plain TCP/IP sockets, because the network can go down any moment.

Again, this suggests to me that the test client you're talking about
writing is strictly for use in testing the server, and that the test
client code isn't going to wind up in the final devices at all.

That's true.

Well, it seems to me that it ought to work just like regular DUN on
Windows. That is, the client code should not care at all about the fact
that you're going through a GPRS modem. You should have the GPRS DUN
adapter installed as part of the Windows network configuration. Then when
an Internet connection is needed (eg your test client code tries to access
the server), Windows can automatically connect the GPRS modem to the
Internet.

I don't see why your test client code needs to know anything at all about
GPRS. If you do, perhaps you could explain that part in more detail.

The main reason is because I'll need to actually talk with the modem in the
production code, so I'm trying to get a grip on how to handle it, by using a
simulated client that talks with the modem by a serial port. I can of course
wait for the actual hardware to be available, but I'd really like to be able
to do some tests by now. But in order to do that, I need a TCP/IP stack to
run over a serial line.


Massimo

 

[Peter Duniho]

[...]
The main reason is because I'll need to actually talk with the modem in
the production code, so I'm trying to get a grip on how to handle it, by
using a simulated client that talks with the modem by a serial port. I can
of course wait for the actual hardware to be available, but I'd really
like to be able to do some tests by now. But in order to do that, I need a
TCP/IP stack to run over a serial line.

I'm not sure that's true. That is, such a thing already exists (for
example, this is essentially what the DUN stuff does), but it doesn't allow
you to test the part of the code you seem to want to test.

It seems to me that if you want to test managing the GPRS hardware itself,
you need to actually write the network adapter driver itself. That is, the
component that allows Windows to create a TCP/IP adapter through a GPRS
modem.

If you have something that already implements the TCP/IP stack over a serial
line, then by the time your application can interact with it, it already
looks like TCP/IP.

Personally, I'm not sure I see the value in doing what you want to do. That
is, I'm guessing GPRS dial-up network drivers already exist (so there's no
need to do it yourself for the purpose of getting the actual functionality),
and it's very likely that the hard parts of actually controlling the
hardware (actually getting the serial port open, managing the configuration
of the port, translating that into something that looks like TCP/IP to the
client software, etc) are going to be very different on the actual device
than under a Windows test platform.

But, assuming you really believe this is important, from your description it
sounds to me as though you are signing up to write a network adapter driver.

In any case, no...I believe the answer to your question is that there is not
any support for such a thing in .NET, not in the way you appear to be asking
for. Obviously, you could interact with an existing TCP/IP adapter using
..NET, once it's been connected by Windows. But I'm pretty sure .NET doesn't
include any of the actual TCP/IP management functionality within it. All
that is in the lower-level network drivers, and even if .NET did handle the
TCP/IP protocol stuff itself, I doubt that the raw details would be
accessible to a .NET program.

Pete

 

[Massimo]

I'm not sure that's true. That is, such a thing already exists (for
example, this is essentially what the DUN stuff does), but it doesn't
allow you to test the part of the code you seem to want to test.

At this point of the development process, I need to test how to
connect/disconnect the modem (AT commands) and how well TCP/IP can handle
those situations where the link goes down due to GSM/GPRS network troubles;
the modem behaves just like a plain old serial modem once it's connected,
but the connection is actually quite unreliable, and when it drops that
isn't always reported immediately, i.e. the connection can drop and the
controlling software will only know this after some seconds.
I need to know how TCP/IP can handle this, and if a TCP/IP client will have
exact knowledge of how many data actually reached the remote server;
besides, I also need to test the AT command set the modem uses.

That's why I need a TCP/IP stack to run over the modem's connection once
it's established.

Of course, Windows' DUN can handle this (it's his job); but when it does, an
application loses any connection to the actual hardware and simply uses a
TCP/IP socket; things also can get a lot more complicated because usually a
computer also have some "real" network adapter which the OS's TCP/IP stack
uses.

If you have something that already implements the TCP/IP stack over a
serial line, then by the time your application can interact with it, it
already looks like TCP/IP.

That's right.

Personally, I'm not sure I see the value in doing what you want to do.
That is, I'm guessing GPRS dial-up network drivers already exist (so
there's no need to do it yourself for the purpose of getting the actual
functionality), and it's very likely that the hard parts of actually
controlling the hardware (actually getting the serial port open, managing
the configuration of the port, translating that into something that looks
like TCP/IP to the client software, etc) are going to be very different on
the actual device than under a Windows test platform.

That's right; but the modem usage will not vary, since that is managed using
its own set of AT commands over the serial port (and that's what I need to
test now).

In any case, no...I believe the answer to your question is that there is
not any support for such a thing in .NET, not in the way you appear to be
asking for. Obviously, you could interact with an existing TCP/IP adapter
using .NET, once it's been connected by Windows. But I'm pretty sure .NET
doesn't include any of the actual TCP/IP management functionality within
it. All that is in the lower-level network drivers, and even if .NET did
handle the TCP/IP protocol stuff itself, I doubt that the raw details
would be accessible to a .NET program.

That's exactly what I was thinking about it.

Thanks.


Massimo