UDP Network support

[Sebastian Schocke]

Just did a new check-in with limited UDP support

The UdpClient class can be used to send UDP packets. No receiving YET... am working on it.

http://cosmos.codeplex.com/SourceControl/changeset/changes/88981

[Callum McGing]

Yay!

[Chad Z. Hower aka Kudzu]

Post by Sebastian Schocke
Just did a new check-in with limited UDP support
The UdpClient class can be used to send UDP packets. No receiving YET... am working on it.

Thats great!!!

[Sebastian Schocke]

Was wondering... if I finish adding support for UDP (send and receive), does that mean we can start adding debugging over Ethernet?

Was thinking of it as follows...
- User calls NetworkStack.ConfigIP() to configure the network
- Kernel then automatically sends a UDP broadcast to try and find the debugger
- our VS Debugger then replies to the broadcast
- Kernel receives the reply, and saves the debug IP
- From then on, instead of sending to serial everytime the debugstub is called, send using UDP instead

I have not looked at the actual debugger or debugstub implementation, so I don't know how realistic this is.

Also, I am sure we will have to bring in some feature for re-using a UDPPacket instance, because allocating a byte buffer everytime we call the debugstub is impossible memory wise, but I think I can make that work quite easily if someone can tackle the debugstub and VS debugger part.

I think it may be up to 5x faster than the serial implementation, if done correctly.

Thoughts?

----- Original Message -----
From: "Chad Z. Hower aka Kudzu" <Chad-***@public.gmane.org>
To: Cosmos-Dev-***@public.gmane.org
Sent: Saturday, March 3, 2012 2:28:45 PM
Subject: Re: [Cosmos-Dev] UDP Network support

Post by Sebastian Schocke
Just did a new check-in with limited UDP support
The UdpClient class can be used to send UDP packets. No receiving YET... am working on it.

Thats great!!!

[Matthijs ter Woord]

Chad knows this better, but I think this is going to be really hard: the
debugstub is handwritten (using X#) assembler code..

Also one might wonder if we want to use normal kernel code (at least in
this stage) because it would mean it's impossible to use the debugger on
the network code (i think)..

Post by Sebastian Schocke
Was wondering... if I finish adding support for UDP (send and receive),
does that mean we can start adding debugging over Ethernet?
Was thinking of it as follows...
- User calls NetworkStack.ConfigIP() to configure the network
- Kernel then automatically sends a UDP broadcast to try and find the debugger
- our VS Debugger then replies to the broadcast
- Kernel receives the reply, and saves the debug IP
- From then on, instead of sending to serial everytime the debugstub is
called, send using UDP instead
I have not looked at the actual debugger or debugstub implementation, so I
don't know how realistic this is.
Also, I am sure we will have to bring in some feature for re-using a
UDPPacket instance, because allocating a byte buffer everytime we call the
debugstub is impossible memory wise, but I think I can make that work quite
easily if someone can tackle the debugstub and VS debugger part.
I think it may be up to 5x faster than the serial implementation, if done correctly.
Thoughts?
----- Original Message -----
Sent: Saturday, March 3, 2012 2:28:45 PM
Subject: Re: [Cosmos-Dev] UDP Network support

Post by Sebastian Schocke
Just did a new check-in with limited UDP support
The UdpClient class can be used to send UDP packets. No receiving YET...
am working on it.

Thats great!!!
------------------------------------
--------------------------------------------------
More things to join for Cosmos!
http://tinyurl.com/pc7bds
http://tinyurl.com/qhttde
http://tinyurl.com/plrloa
--------------------------------------------------
Yahoo! Groups Links

[Chad Z. Hower aka Kudzu]

Post by Sebastian Schocke
Was wondering... if I finish adding support for UDP (send and receive),
does that mean we can start adding debugging over Ethernet?

No.

Any debugstub code must run COMPLETELY independent of Cosmos. Because if
Cosmos code gets goofed up, so will the DS.. DS cant debug a corrupt
stack or code if it itself is corrupted....

The plan for debugging over ethernet is raw packets, but it has to be
written in pure ASM and self standing....

[Sebastian Schocke]

Hmmmm... seems like a tall task in my opinion. Especially if you ever plan on supporting anything more than say VMWare... considering you would have to write a driver in pure asm for the debugstub for each network card.

I don't understand this insistence on complete independence at all though. The debugstub call is changed to a method written in C# instead of ASM... so what. And if the Cosmos code gets goofed up, and one needs to debug the stack, or something even more low level, just disable the UDP debugger in project settings, and debug away using current debugger.

Also, just a thought. If you were to code the debugstub to use the nic, how would you differentiate between data to be handled in the debugger, or pass to the network stack. It would seem to me in your scenario, it would most likely be either/or... Either have a network stack, or network debugging... Just my 2 cents

----- Original Message -----
From: "Chad Z. Hower aka Kudzu" <Chad-***@public.gmane.org>
To: Cosmos-Dev-***@public.gmane.org
Sent: Monday, March 5, 2012 4:25:25 PM
Subject: Re: [Cosmos-Dev] UDP Network support

Post by Sebastian Schocke
Was wondering... if I finish adding support for UDP (send and receive),
does that mean we can start adding debugging over Ethernet?

No.

Any debugstub code must run COMPLETELY independent of Cosmos. Because if
Cosmos code gets goofed up, so will the DS.. DS cant debug a corrupt
stack or code if it itself is corrupted....

The plan for debugging over ethernet is raw packets, but it has to be
written in pure ASM and self standing....

[Chad Z. Hower aka Kudzu]

Post by Sebastian Schocke
Hmmmm... seems like a tall task in my opinion. Especially if you ever
plan on supporting anything more than say VMWare... considering you
would have to write a driver in pure asm for the debugstub for each
network card.

Yes, but its necessary. This is why serial cable will be necessary on
many machines, and on others a "known" network card. If you support 2-3
in base mode you can get the most popular ones anyways. Many still offer
NE2000 emulation at the base level.

Post by Sebastian Schocke
I don't understand this insistence on complete independence at all
though. The debugstub call is changed to a method written in C# instead
of ASM... so what. And if the Cosmos code gets goofed up, and one needs

What happens when Cosmos goes awry and gets corrupt? It will take DS
with it.. then debugging will be *completely* useless at the time you
need it the very most.

Post by Sebastian Schocke
to debug the stack, or something even more low level, just disable the
UDP debugger in project settings, and debug away using current debugger.

For higher level functions it might work.

Post by Sebastian Schocke
Also, just a thought. If you were to code the debugstub to use the nic,
how would you differentiate between data to be handled in the debugger,
or pass to the network stack. It would seem to me in your scenario, it
would most likely be either/or... Either have a network stack, or
network debugging... Just my 2 cents

You will need 2 NICs....