Hi,
I am facing a problem which anyone who has worked on any UDP
application might have faced.
UDP by itself is unreliable. If packets are lost, no acknowledgements
are sent.

I have a UDP application which is receiving packets on a standard port.
It receives packets asynchronously. At any time any packet can arrive.
The problem is that sometimes a number of packets arrive and our UDP
socket buffer ( being of finite size ) is not able
to handle them and simply drops the packet.
The UDP socket buffer cannot be increased beyond a finite size(
dynamically it cannot be increased, it is fixed for an OS) .

So a number of packets simply drop with out any intimation to the
receiver/sender.

I need to have checkpoint ( some kind of intimation ) that the packets
are being dropped.

I have implemented polling with poll parameter as POLLIN or
POLLRDNORM.( I have tried both parameters)
Both implementation works that is gives me a poll status implying
socket buffer is full.

In my test set up I can control the rate at which packets are
generated.
When the packets are sent at a very high rate and my socket buffer is
not able to handle them, polling status tells me that
buffer is full.

when the rate of sending packets is slow, I get an intimation that
buffer space is available.

But in some cases ( when the rate of sending packets is slow ), I get a
poll status that buffer is full ( which is wrong ). Even though
these are corner cases but it made me think.( and caused worry) .

I have following queries..

a) Do we have any mechanism/ way in which we can find that udp socket
buffer is full and packets are being dropped.
b) Can polling be actually be used. My corner cases made me think that.
Is my approach totally wrong.
c) If not Polling then what ?
d) If polling can be used, which other parameters I can use to avoid
these corner case.

e) Is my implementation of polling wrong, Is it possible that I am
misunderstanding the polling status to tell whether
buffer is full.

if you have some idea about this issue please let me know.
If you need some more input from my end let me know.
You can mail me at vishal21@gmail.com

Vishal wrote:
> Hi,
> I am facing a problem which anyone who has worked on any UDP
> application might have faced.
> UDP by itself is unreliable. If packets are lost, no acknowledgements
> are sent.
>
> I have a UDP application which is receiving packets on a standard port.
> It receives packets asynchronously. At any time any packet can arrive.
> The problem is that sometimes a number of packets arrive and our UDP
> socket buffer ( being of finite size ) is not able
> to handle them and simply drops the packet.
> The UDP socket buffer cannot be increased beyond a finite size(
> dynamically it cannot be increased, it is fixed for an OS) .

No it's not: you can change it dynamically via
setsockopt(...SO_RCVBUFSIZE ) and if you're on a Windows platform that's
the first thing you should do, because the default is a miserable 8k.

> I have implemented polling with poll parameter as POLLIN or
> POLLRDNORM.( I have tried both parameters)
> Both implementation works that is gives me a poll status implying
> socket buffer is full.

No it doesn't, it implies that there is *some* data in the socket buffer.

But in any case the technique is flawed. Unless the packets contain
sequence numbers, you can't tell *at the receiver* that packets are
being dropped. You can only tell *at the sender* by the ACKs or NACKs
that the receiver sends back.

Vishal wrote:

> I am facing a problem which anyone who has worked on any UDP
> application might have faced.
> UDP by itself is unreliable. If packets are lost, no acknowledgements
> are sent.

Well, UDP doesn't send acknowledgements. That doesn't mean that an
application can't send acknowledgements.

> I have a UDP application which is receiving packets on a standard port.
> It receives packets asynchronously. At any time any packet can arrive.
> The problem is that sometimes a number of packets arrive and our UDP
> socket buffer ( being of finite size ) is not able
> to handle them and simply drops the packet.
> The UDP socket buffer cannot be increased beyond a finite size(
> dynamically it cannot be increased, it is fixed for an OS) .

It can be increased, but that won't solve the problem. UDP packets can
be dropped, period. Any application that can't deal with this fact is
broken.

> So a number of packets simply drop with out any intimation to the
> receiver/sender.

Right. So people who use UDP *must* design their applications with that
in mind. Otherwise, the application is broken.

> I need to have checkpoint ( some kind of intimation ) that the packets
> are being dropped.

Okay, so add code to do that. For example, you could have each side
tell the other how many packets it has recieved from time to time. Or
you could put an incrementing sequence number in each packet and tell
one side if you miss a sequence number. (Though you might receive it
just after because UDP packets can be received out of order.)

If you're not prepared to deal with this, and don't time your sending
so as not to overwhelm the buffers, don't use UDP. Use TCP. It has its
own transmit pacing, reordering, and retransmissions.

> I have implemented polling with poll parameter as POLLIN or
> POLLRDNORM.( I have tried both parameters)
> Both implementation works that is gives me a poll status implying
> socket buffer is full.

You mean non-empty.

> In my test set up I can control the rate at which packets are
> generated.
> When the packets are sent at a very high rate and my socket buffer is
> not able to handle them, polling status tells me that
> buffer is full.

The 'poll' function tells you the buffer is non-empty.

> when the rate of sending packets is slow, I get an intimation that
> buffer space is available.
>
> But in some cases ( when the rate of sending packets is slow ), I get a
> poll status that buffer is full ( which is wrong ). Even though
> these are corner cases but it made me think.( and caused worry) .

The 'poll' function does not tell you the buffer is full. It tells you
it might be non-empty when you try to read from it.

> I have following queries..
>
> a) Do we have any mechanism/ way in which we can find that udp socket
> buffer is full and packets are being dropped.

Since that's not the only reason packets might drop, you have to deal
with cases that wouldn't detect anyway. Do *you* have a mechanism? I
don't know. If you don't, you should definitely add one.

> b) Can polling be actually be used. My corner cases made me think that.
> Is my approach totally wrong.
> c) If not Polling then what ?
> d) If polling can be used, which other parameters I can use to avoid
> these corner case.
>
> e) Is my implementation of polling wrong, Is it possible that I am
> misunderstanding the polling status to tell whether
> buffer is full.

You are misunderstanding. The 'poll' function is telling you that the
buffer is currently non-empty and it would be a good idea to try a
'recv' or 'recvmsg'.

It's hard to give you advice because you don't tell us anything about
your I/O strategy or application protocol.

DS

Can a network card detect a dropped/missed packet ?

Maybe but maybe not.

Windows could detect dropped packets... especially the "receive buffer is
full" scenerio could be detected and notified or flag set or so.

But maybe windows does not do this.

Using and modifieing a driver like NDISPROT might reduce the number of
packets dropped because of limited receive buffer size.

You might wanna look into NDISPROT but it's for ethernet cards only...

Winsock is more all around.

I am not even sure if you using windows

I could check your posting headers which might reveal something but why
bother

Bye,
Skybuck

In article <ej3vsp$baf$1@news4.zwoll1.ov.home.nl>,
"Skybuck Flying" <spam@hotmail.com> wrote:

> Can a network card detect a dropped/missed packet ?

Only if it were dropped by the card itself. If it were dropped by a
router along the way, or corrupted in transit, there's no way for the
network card of an endpoint machine to know about this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-DE4506.11103711112006@comcast.dca.giganews.com...
> In article <ej3vsp$baf$1@news4.zwoll1.ov.home.nl>,
> "Skybuck Flying" <spam@hotmail.com> wrote:
>
>> Can a network card detect a dropped/missed packet ?
>
> Only if it were dropped by the card itself. If it were dropped by a
> router along the way, or corrupted in transit, there's no way for the
> network card of an endpoint machine to know about this.

If the network card can detect the postamble then it knows it missed the
preamble.

So it missed a packet or something

Bye,
Skybuck.

In article <ej5992$tk0$1@news2.zwoll1.ov.home.nl>,
"Skybuck Flying" <spam@hotmail.com> wrote:

> "Barry Margolin" <barmar@alum.mit.edu> wrote in message
> news:barmar-DE4506.11103711112006@comcast.dca.giganews.com...
> > In article <ej3vsp$baf$1@news4.zwoll1.ov.home.nl>,
> > "Skybuck Flying" <spam@hotmail.com> wrote:
> >
> >> Can a network card detect a dropped/missed packet ?
> >
> > Only if it were dropped by the card itself. If it were dropped by a
> > router along the way, or corrupted in transit, there's no way for the
> > network card of an endpoint machine to know about this.
>
> If the network card can detect the postamble then it knows it missed the
> preamble.
>
> So it missed a packet or something

But if the packet were dropped by a router along the way, your network
card would never see any of this.

If someone mails you a postcard, but the post office misplaces it, can
you tell that you missed something?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Hi Skybuck,

Skybuck Flying wrote:
> Can a network card detect a dropped/missed packet ?
>
> Maybe but maybe not.

I loosing packets at the UDP layer. So LAN card will not be able to
make out whether the packets are beingdropped. But may be if we can
find the packets actually receive at the LAN card and packets actually
received at the UDP layer that will be ful, The difference will
tell me if packets are lost at the UDP socket,
>
> Windows could detect dropped packets... especially the "receive buffer is
> full" scenerio could be detected and notified or flag set or so.
>
> But maybe windows does not do this.
>

My code works in windows. So do you know of any flag in windows which
will be set in case the packets are getting dropped ??
> Using and modifieing a driver like NDISPROT might reduce the number of
> packets dropped because of limited receive buffer size.
>
> You might wanna look into NDISPROT but it's for ethernet cards only...
>
> Winsock is more all around.
>
> I am not even sure if you using windows
>
> I could check your posting headers which might reveal something but why
> bother
>

I have given all the relevant detail. If you think I can give some more
information let me know,I will answer your specific questions,
Thanks and regards,
Vishal
> Bye,
> Skybuck

Maybe IP er API can provide some information.

It does have some information about dropped packets.

I never used it much though.

Bye,
Skybuck.

On Sun, 12 Nov 2006 09:33:02 -0800, guddu wrote:

>
> Hi Skybuck,
>
> Skybuck Flying wrote:
>> Can a network card detect a dropped/missed packet ?
>>
>> Maybe but maybe not.
>
> I loosing packets at the UDP layer. So LAN card will not be able to
> make out whether the packets are beingdropped. But may be if we can
> find the packets actually receive at the LAN card and packets actually
> received at the UDP layer that will be ful, The difference will
> tell me if packets are lost at the UDP socket,

Use a network sniffer. Ethereal is great for this kind of work. And free.

M4
--
Redundancy is a great way to introduce more single points of failure.

"Barry Margolin" <barmar@alum.mit.edu> wrote:

>> > "Skybuck Flying" <spam@hotmail.com> wrote:
>> >
>> >> Can a network card detect a dropped/missed packet ?

>> If the network card can detect the postamble then it knows it missed
>> the
>> preamble.
>>
>> So it missed a packet or something
>
> But if the packet were dropped by a router along the way, your network
> card would never see any of this.
>
> If someone mails you a postcard, but the post office misplaces it, can
> you tell that you missed something?

Maybe this has been mentioned in this long thread. The simplest way to
have a UDP sink device know if packets have been missed is to provide a
sequence number with each packet. Then the destination application can
detect missing packets and perhaps the system has been set up to allow
for (unicast) requests for missing data, from destination to source. Or
maybe it's enough for the destination to know it missed an update. All
depends how you design this thing to operate.

For example, suppose a system multicasts periodic UDP status messages,
and sets a bit if a change has occurred in this periodic status.
Including such a "changed status" bit is a good way for a destination
device to avoid having to decode the entire status packet each time, but
only if it's certain that it received the previous status.

In a system like this, it's sufficient for the destination to know that
it missed a status packet, and treat the new arrival as if a change had
coccurred.

Bert

EJP wrote:
> Vishal wrote:
> > Hi,
> > I am facing a problem which anyone who has worked on any UDP
> > application might have faced.
> > UDP by itself is unreliable. If packets are lost, no acknowledgements
> > are sent.
> >
> > I have a UDP application which is receiving packets on a standard port.
> > It receives packets asynchronously. At any time any packet can arrive.
> > The problem is that sometimes a number of packets arrive and our UDP
> > socket buffer ( being of finite size ) is not able
> > to handle them and simply drops the packet.
> > The UDP socket buffer cannot be increased beyond a finite size(
> > dynamically it cannot be increased, it is fixed for an OS) .
>
> No it's not: you can change it dynamically via
> setsockopt(...SO_RCVBUFSIZE ) and if you're on a Windows platform that's
> the first thing you should do, because the default is a miserable 8k.

Hi EJP,
I know using setsockopt I can change the buffer size. But I should be
able to know "when" to do that. For that I need to have an intimation
that the many packets have arrived and they are being dropped. Once I
know that I can increase the buffer size.

>
> > I have implemented polling with poll parameter as POLLIN or
> > POLLRDNORM.( I have tried both parameters)
> > Both implementation works that is gives me a poll status implying
> > socket buffer is full.
>
> No it doesn't, it implies that there is *some* data in the socket buffer.
>
> But in any case the technique is flawed. Unless the packets contain
> sequence numbers, you can't tell *at the receiver* that packets are
> being dropped. You can only tell *at the sender* by the ACKs or NACKs
> that the receiver sends back.

Anyways you have pointed out that my techinque is flawed. That is
infact great .

Regards,
Vishal

EJP wrote:
> Vishal wrote:
> > Hi,
> > I am facing a problem which anyone who has worked on any UDP
> > application might have faced.
> > UDP by itself is unreliable. If packets are lost, no acknowledgements
> > are sent.
> >
> > I have a UDP application which is receiving packets on a standard port.
> > It receives packets asynchronously. At any time any packet can arrive.
> > The problem is that sometimes a number of packets arrive and our UDP
> > socket buffer ( being of finite size ) is not able
> > to handle them and simply drops the packet.
> > The UDP socket buffer cannot be increased beyond a finite size(
> > dynamically it cannot be increased, it is fixed for an OS) .
>
> No it's not: you can change it dynamically via
> setsockopt(...SO_RCVBUFSIZE ) and if you're on a Windows platform that's
> the first thing you should do, because the default is a miserable 8k.

Hi EJP,
I know using setsockopt I can change the buffer size. But I should be
able to know "when" to do that. For that I need to have an intimation
that the many packets have arrived and they are being dropped. Once I
know that I can increase the buffer size.

>
> > I have implemented polling with poll parameter as POLLIN or
> > POLLRDNORM.( I have tried both parameters)
> > Both implementation works that is gives me a poll status implying
> > socket buffer is full.
>
> No it doesn't, it implies that there is *some* data in the socket buffer.
>
> But in any case the technique is flawed. Unless the packets contain
> sequence numbers, you can't tell *at the receiver* that packets are
> being dropped. You can only tell *at the sender* by the ACKs or NACKs
> that the receiver sends back.

Anyways you have pointed out that my techinque is flawed. Moreover
suggesting to use ACK is infact great .

Regards,
Vishal

Hi Albert,
In my case each packet arrives individually. My UDP application gets
unique unrelated packets from different sources. So I cannot put
sequence numbers for each packet as each packet is independant.

Regards,
Vishal

Albert Manfredi wrote:
> "Barry Margolin" <barmar@alum.mit.edu> wrote:
>
> >> > "Skybuck Flying" <spam@hotmail.com> wrote:
> >> >
> >> >> Can a network card detect a dropped/missed packet ?
>
> >> If the network card can detect the postamble then it knows it missed
> >> the
> >> preamble.
> >>
> >> So it missed a packet or something
> >
> > But if the packet were dropped by a router along the way, your network
> > card would never see any of this.
> >
> > If someone mails you a postcard, but the post office misplaces it, can
> > you tell that you missed something?
>
> Maybe this has been mentioned in this long thread. The simplest way to
> have a UDP sink device know if packets have been missed is to provide a
> sequence number with each packet. Then the destination application can
> detect missing packets and perhaps the system has been set up to allow
> for (unicast) requests for missing data, from destination to source. Or
> maybe it's enough for the destination to know it missed an update. All
> depends how you design this thing to operate.
>
> For example, suppose a system multicasts periodic UDP status messages,
> and sets a bit if a change has occurred in this periodic status.
> Including such a "changed status" bit is a good way for a destination
> device to avoid having to decode the entire status packet each time, but
> only if it's certain that it received the previous status.
>
> In a system like this, it's sufficient for the destination to know that
> it missed a status packet, and treat the new arrival as if a change had
> coccurred.
>


> Bert

Skybuck Flying wrote:
> Maybe IP er API can provide some information.
>

Can you give me some more information about IP er API. How do we
use it in Windows and Unix ???


> It does have some information about dropped packets.
>
> I never used it much though.
>
> Bye,
> Skybuck.

"guddu" <vishal21@gmail.com> wrote:

> In my case each packet arrives individually. My UDP application gets
> unique unrelated packets from different sources. So I cannot put
> sequence numbers for each packet as each packet is independant.

Would it be possible to associate each sequence number with an IP source
address? You could keep track of sequence numbers that way perhaps.

Bert

"guddu" <vishal21@gmail.com> wrote in message
news:1163396743.127973.139420@m73g2000cwd.googlegr oups.com...
>
>
> Skybuck Flying wrote:
>> Maybe IP er API can provide some information.
>>
>
> Can you give me some more information about IP er API. How do we
> use it in Windows and Unix ???

Euhm...

Google it, try microsoft's files... check reference manual or MSDN etc.

(Microsoft Developer Network)

I don't know about Unix though Linux might have windows api implemented
via wine or so... (?)

Also you could use netstat to see some information for example:

Go to an ms-dos prompt and type:

netstat -s -e

The -s switch will show statistics for internet protocols and the -e switch
for ethernet/interface.

Here is an example:

"
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator>netstat -s -e
Interface Statistics

Received Sent

Bytes 1453658 552320
Unicast packets 3567 3500
Non-unicast packets 14999 14
Discards 0 0
Errors 0 0
Unknown protocols 0

IPv4 Statistics

Packets Received = 3576
Received Header Errors = 0
Received Address Errors = 3
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 54
Received Packets Delivered = 3536
Output Requests = 3509
Routing Discards = 0
Discarded Output Packets = 0
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0

ICMPv4 Statistics

Received Sent
Messages 2 3048
Errors 0 0
Destination Unreachable 1 3044
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 0 0
Echos 1 0
Echo Replies 0 1
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0

TCP Statistics for IPv4

Active Opens = 8
Passive Opens = 0
Failed Connection Attempts = 0
Reset Connections = 1
Current Connections = 1
Segments Received = 466
Segments Sent = 439
Segments Retransmitted = 0

UDP Statistics for IPv4

Datagrams Received = 15
No Ports = 6101
Receive Errors = 0
Datagrams Sent = 20

C:\Documents and Settings\Administrator>
"

For example it shows some packets were discarded.

Not sure what it exactly means...

Maybe this information could be usefull for you.

Bye,
Skybuck.

"guddu" <vishal21@gmail.com> wrote in message
news:1163396569.492873.62790@h54g2000cwb.googlegro ups.com...
>
> Hi Albert,
> In my case each packet arrives individually. My UDP application gets
> unique unrelated packets from different sources. So I cannot put
> sequence numbers for each packet as each packet is independant.

The identification field of the IP header could be a sequence number from
each host, depends on how the stack/operating system uses it

If they only communicating with you and no other IP traffic happens on those
hosts, the identification field might be usuable as a sequence number

Bye,
Skybuck.

In article <eja6nt$587$1@news6.zwoll1.ov.home.nl>,
"Skybuck Flying" <spam@hotmail.com> wrote:

> "guddu" <vishal21@gmail.com> wrote in message
> news:1163396569.492873.62790@h54g2000cwb.googlegro ups.com...
> >
> > Hi Albert,
> > In my case each packet arrives individually. My UDP application gets
> > unique unrelated packets from different sources. So I cannot put
> > sequence numbers for each packet as each packet is independant.
>
> The identification field of the IP header could be a sequence number from
> each host, depends on how the stack/operating system uses it
>
> If they only communicating with you and no other IP traffic happens on those
> hosts, the identification field might be usuable as a sequence number

Except that no API other than raw sockets provides a way for the
application to get the ID field.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin <barmar@alum.mit.edu> wrote:
> Except that no API other than raw sockets provides a way for the
> application to get the ID field.

And there were even one stack which, when they believed the IP
datagram was not going to be fragmented (ie believing that all the
intermediate devices would honor the DF bit) would set the IP ID to 0
for all datagrams.

And even if they didn't set the ID to 0, there is no guarantee that
the IP ID's would be "contiguous" between the UDP endpoints - a host
is (was?) free to assign IP ID's globally or on an IP address-pair
basis. So, for most incense and porpoises, one would have to assume
that the sequence of incoming IP datagram IDs were discontinuous for a
"contiguous" stream of UDP datagrams between the endpoints, even if
they might still appear to be monotonically increasing.

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <Iz96h.2419$0D3.1514@news.cpqcorp.net>,
Rick Jones <rick.jones2@hp.com> wrote:

>that the sequence of incoming IP datagram IDs were discontinuous for a
>"contiguous" stream of UDP datagrams between the endpoints, even if
>they might still appear to be monotonically increasing.

What's that about monotone increasing IP IDs? As far as I can tell
from a quick peek at the source, the FreeBSD 6.* sysctl net.inet.ip.random_id
does what it sounds like.


Vernon Schryver vjs@rhyolite.com

Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
> In article <Iz96h.2419$0D3.1514@news.cpqcorp.net>,
> Rick Jones <rick.jones2@hp.com> wrote:

>>that the sequence of incoming IP datagram IDs were discontinuous for a
>>"contiguous" stream of UDP datagrams between the endpoints, even if
>>they might still appear to be monotonically increasing.

> What's that about monotone increasing IP IDs? As far as I can tell
> from a quick peek at the source, the FreeBSD 6.* sysctl
> net.inet.ip.random_id does what it sounds like.

Final nail in the coffin then

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

"Rick Jones" <rick.jones2@hp.com> wrote in message
news:pKn6h.2434$314.1207@news.cpqcorp.net...
> Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
>> In article <Iz96h.2419$0D3.1514@news.cpqcorp.net>,
>> Rick Jones <rick.jones2@hp.com> wrote:
>
>>>that the sequence of incoming IP datagram IDs were discontinuous for a
>>>"contiguous" stream of UDP datagrams between the endpoints, even if
>>>they might still appear to be monotonically increasing.
>
>> What's that about monotone increasing IP IDs? As far as I can tell
>> from a quick peek at the source, the FreeBSD 6.* sysctl
>> net.inet.ip.random_id does what it sounds like.
>
> Final nail in the coffin then

What about Windows and Unix <- original poster mentioned operating systems ?

Bye,
Skybuck.

Skybuck Flying <spam@hotmail.com> wrote:
> "Rick Jones" <rick.jones2@hp.com> wrote in message
>> Final nail in the coffin then

> What about Windows and Unix <- original poster mentioned operating
> systems ?

FreeBSD is one of the Unix OSes out there.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

"Rick Jones" <rick.jones2@hp.com> wrote in message
news:Pmt6h.2470$_44.2084@news.cpqcorp.net...
> Skybuck Flying <spam@hotmail.com> wrote:
>> "Rick Jones" <rick.jones2@hp.com> wrote in message
>>> Final nail in the coffin then
>
>> What about Windows and Unix <- original poster mentioned operating
>> systems ?
>
> FreeBSD is one of the Unix OSes out there.

Has there ever been a Unix kernel where the identification field was simply
incremented ?

Bye,
Skybuck.