thousands of request in one port per second

P

Praki

Greetings All,

i think this is the right group to post this question.

i am working on client server model. in this model the client is
sending request in thousands in number. for example per sec around
2000 to 3000 request is coming. so the server is listening in the udp
port. after some time the most of the request is dropped. how can
manage this problem. is the multi threading will help ? but it is UDP
port i dont know how handle this request in multi threading model. or
is there any way i can handle this problem ?

thanks in advance

Prakash
 
C

CBFalconer

Praki said:
i think this is the right group to post this question.

i am working on client server model. in this model the client is
sending request in thousands in number. for example per sec
around 2000 to 3000 request is coming. so the server is listening
in the udp port. after some time the most of the request is
dropped. how can manage this problem. is the multi threading will
help ? but it is UDP port i dont know how handle this request in
multi threading model. or is there any way i can handle this
problem ?

Wrong newsgroup. We handle standard C, as described in the C
standard. The language contains none of clients, servers,
threading, UDP, etc. You probably need a newsgroup that deals with
your particular system.
 
A

Antoninus Twink

i think this is the right group to post this question.

It's a perfectly appropriate group. Please ignore CBF, who is a known
troll, and senile to boot.
i am working on client server model. in this model the client is
sending request in thousands in number. for example per sec around
2000 to 3000 request is coming. so the server is listening in the udp
port. after some time the most of the request is dropped. how can
manage this problem. is the multi threading will help ? but it is UDP
port i dont know how handle this request in multi threading model. or
is there any way i can handle this problem ?

If dropped packets is a serious problem, you shouldn't be using UDP.

You could try increasing the size of the receiving buffer, e.g.:

int bufsize = 1<<16;
setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &bufsize, sizeof bufsize);

If that fails, you could maintain your own buffer: your main thread
could just transfer data from the socket buffer to your buffer, and then
a worker thread could process items from your buffer. But ultimately, if
data is coming in faster than you can process it, then any buffer will
eventually overflow...
 
R

Richard

Keith Thompson said:
Praki said:
Greetings All,

i think this is the right group to post this question.
[...]

I'm afraid it really isn't. You'll bet better information from a
larger pool of experts in a group that deals with your operating
system, most likely comp.unix.programmer if you're on Linux or some
other Unix-like system, or comp.os.ms-windows.programmer.win32 or one
of the microsoft.* groups if you're on MS Windows.

I'm sorry that you've run into Antoninus Twink, a troll who sometimes
pretends to be helpful. If he were really interested in helping you
solve your problem rather than disrupting this newsgroup, he probably
would have told you about the existence of other more appropriate
groups.

Or he could help a little bit to get the OP thinking. Do you really know
nothing other than the petty small print in the standard?

If someone asks you the way somewhere do you tell them to **** off and
consult a certified map in the hands of a professional orienteering
scout or do you say "it's in that direction"?

Sometimes the specialist groups are the worst to ask in because the regs
in those groups are so full of their own self importance, that they are
unable to form a dialog with a beginner.
 
R

Richard

CBFalconer said:
Wrong newsgroup. We handle standard C, as described in the C
standard. The language contains none of clients, servers,
threading, UDP, etc. You probably need a newsgroup that deals with
your particular system.

Don't be ridiculous. Many aspects of these things can be done in standard
C and this is a good place to ask C programmers of their thoughts and
experiences. The fact that you have never programmed on a real
professional C project does not mean the rest here have not.
 
U

user923005

Greetings All,

i think this is the right group to post this question.

Probably not. I suggest if you don't mind C++
solutions.
Using ACE would allow a fast, portable and reliable approach.
Building clients and servers with ACE is as easy as falling off a log.
i am working on client server model. in this model the client is
sending request in thousands in number. for example per sec around
2000 to 3000 request is coming. so the server is listening in the udp
port. after some time the most of the request is dropped. how can
manage this problem. is the multi threading will help  ? but it is UDP
port i dont know how handle this request in multi threading model. or
is there  any way i can handle this problem ?

UDP gives no guarantees about delivery. If you need to scale lots of
requests, I suggest looking into memcached.
The memcached tool set is also a little unreliable (because it is a
cache), but it will scale to any load you can imagine.
http://en.wikipedia.org/wiki/Memcached
 
I

Ian Collins

Praki said:
Greetings All,

i think this is the right group to post this question.

i am working on client server model. in this model the client is
sending request in thousands in number. for example per sec around
2000 to 3000 request is coming. so the server is listening in the udp
port. after some time the most of the request is dropped. how can
manage this problem. is the multi threading will help ? but it is UDP
port i dont know how handle this request in multi threading model. or
is there any way i can handle this problem ?
If your server can't keep up, you should profile the code and see where
the bottlenecks are. It you fix those and it still can't keep up, use
faster hardware. If that can't keep up, use more cores and threading.
If that can't keep up, use a more appropriate protocol.

Or save a lot of time and do the last first.
 
I

Ian Collins

user923005 said:
UDP gives no guarantees about delivery. If you need to scale lots of
requests, I suggest looking into memcached.
The memcached tool set is also a little unreliable (because it is a
cache), but it will scale to any load you can imagine.
http://en.wikipedia.org/wiki/Memcached

While memcached is a good tool, if the load is continuous and the server
can't keep up, the cache will fill and packets will continue to be dropped.
 
I

Ian Collins

Richard said:
Don't be ridiculous. Many aspects of these things can be done in standard
C and this is a good place to ask C programmers of their thoughts and
experiences.

OK, put up or shut up. What are your thoughts and experiences? Or are
you just here to snipe form the sidelines?
 
U

user923005

While memcached is a good tool, if the load is continuous and the server
can't keep up, the cache will fill and packets will continue to be dropped.

From the memcached FAQ:

"Finally, memcached itself is implemented as a non-blocking event-
based server. This is an architecture used to solve the C10K problem
and scale like crazy.

What's the big benefit for all this?
Carefully read the above entry (How does memcached work?). The big
benefit, when dealing with giant systems, is memcached's ability to
massively scale out. Since the client does one layer of hashing, it
becomes entirely trivial to add dozens of nodes to the cluster.
There's no interconnect to overload, or multicast protocol to implode.
It Just Works. Run out of memory? Add a few more nodes. Run out of
CPU? Add a few more nodes. Have some spare RAM here and there? Add
nodes!

It's incredibly easy to build on memcached's basic principles to
implement many different kinds of caching architectures. Hopefully
detailed elsewhere in the FAQ."
 
I

Ian Collins

user923005 said:
From the memcached FAQ:

It Just Works. Run out of memory? Add a few more nodes. Run out of
CPU? Add a few more nodes. Have some spare RAM here and there? Add
nodes!
I'm aware of that, but if data arrives even marginally faster than it
can be processed, an infinitely large cache will eventually be required.
 
K

Keith Thompson

Richard said:
Keith Thompson said:
Praki said:
Greetings All,
i think this is the right group to post this question.
[...]

I'm afraid it really isn't. You'll bet better information from a
larger pool of experts in a group that deals with your operating
system, most likely comp.unix.programmer if you're on Linux or some
other Unix-like system, or comp.os.ms-windows.programmer.win32 or one
of the microsoft.* groups if you're on MS Windows.
[snip]
If someone asks you the way somewhere do you tell them to f*** off and
consult a certified map in the hands of a professional orienteering
scout or do you say "it's in that direction"?

Quotation edited for content.

If I happen to know the way, I'll tell them. Sometimes I'll say
something like "It's over that way somewhere; go to that corner and
then ask somebody else". But note that a one-on-one a personal
interaction is not a newsgroup, and directions to the nearest
Starbucks tend to be a lot simpler than answers to technical
questions.

If I don't know the way, but I happen to know that the group of a
dozen people standing a few feet away are expert tour guides with GPS
units, I'll suggest that they go ask one of them. (Metaphor alert:
the "expert tour guides" correspond to the system-specific newsgroup
full of people who know more about, in this case, networking than I
do.)

If somebody asks me for directions in a shopping mall, and I happen to
be standing next to a detailed map of the mall, I'll point to the map
(but I'll be willing to help out if they have trouble reading it,
assuming I have the time).

Antoninus Twink, for whatever reason, is perfectly willing to give
incorrect or incomplete answers, rather than being honest enough to
tell the questioner where to find the real experts. He posts a lot
about Unix programming; it's interesting to note that he rarely posts
in the comp.unix.* groups, where his answers could be checked.

You, on the other hand, rarely contribute anything here but abuse.
You're such a big fan of answering questions, why do you so rarely
answer questions?
 
P

Praki

Richard said:
Keith Thompson said:
Greetings All,
i think this is the right group to post this question.
[...]
I'm afraid it really isn't.  You'll bet better information from a
larger pool of experts in a group that deals with your operating
system, most likely comp.unix.programmer if you're on Linux or some
other Unix-like system, or comp.os.ms-windows.programmer.win32 or one
of the microsoft.* groups if you're on MS Windows.
[snip]
If someone asks you the way somewhere do you tell them to f*** off and
consult a certified map in the hands of a professional orienteering
scout or do you say "it's in that direction"?

Quotation edited for content.

If I happen to know the way, I'll tell them.  Sometimes I'll say
something like "It's over that way somewhere; go to that corner and
then ask somebody else".  But note that a one-on-one a personal
interaction is not a newsgroup, and directions to the nearest
Starbucks tend to be a lot simpler than answers to technical
questions.

If I don't know the way, but I happen to know that the group of a
dozen people standing a few feet away are expert tour guides with GPS
units, I'll suggest that they go ask one of them.  (Metaphor alert:
the "expert tour guides" correspond to the system-specific newsgroup
full of people who know more about, in this case, networking than I
do.)

If somebody asks me for directions in a shopping mall, and I happen to
be standing next to a detailed map of the mall, I'll point to the map
(but I'll be willing to help out if they have trouble reading it,
assuming I have the time).

Antoninus Twink, for whatever reason, is perfectly willing to give
incorrect or incomplete answers, rather than being honest enough to
tell the questioner where to find the real experts.  He posts a lot
about Unix programming; it's interesting to note that he rarely posts
in the comp.unix.* groups, where his answers could be checked.

You, on the other hand, rarely contribute anything here but abuse.
You're such a big fan of answering questions, why do you so rarely
answer questions?

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Hi All,

I chose this group because my implementation going to be in c and also
most of the language which intern uses C to work regarding the socket
programing. So i want to develop my application in C language and
Linux Platform.I cannot change the Protocol because it UDP based SNMP
Protocol.i have respone like a device in SNMP protocol so i cannot
change the protocol. If i act like a thousand device there many be
thousand request to the server at a time.if i ack like a 2000 device
there will be 2000 request at a time. so i want to handle all the
request in UDP protocol. if the server takes long time then client
will go off saying time out. this is my problem.

Prakash
 
I

Ian Collins

Praki said:
Hi All,

I chose this group because my implementation going to be in c and also
most of the language which intern uses C to work regarding the socket
programing. So i want to develop my application in C language and
Linux Platform.I cannot change the Protocol because it UDP based SNMP
Protocol.i have respone like a device in SNMP protocol so i cannot
change the protocol. If i act like a thousand device there many be
thousand request to the server at a time.if i ack like a 2000 device
there will be 2000 request at a time. so i want to handle all the
request in UDP protocol. if the server takes long time then client
will go off saying time out. this is my problem.
If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here. This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.
 
P

Praki

If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here.  This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.

I am sorry for that. is there any pointers for implemeting C threads
for UDP it would be helpfull for me

Thanks,
Praki
 
P

Praki

If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here.  This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.

I am sorry for that. is there any pointers for implemeting C threads
for UDP it would be helpfull for me

Thanks,
Praki
 
P

Praki

If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here.  This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.

I am sorry for that. is there any pointers for implemeting C threads
for UDP it would be helpfull for me

Thanks,
Praki
 
P

Praki

If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here.  This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.

I am sorry for that. is there any pointers for implemeting C threads
for UDP it would be helpfull for me

Thanks,
Praki
 
K

Keith Thompson

Praki said:
Praki said:
I chose this group because my implementation going to be in c and also
most of the language which intern uses C to work regarding the socket
programing. So i want to develop my application in C language and
Linux Platform.
[...]
If your stated your problem, we wouldn't have wasted time with
inappropriate answers.

You have to either limit the number of devices, stagger the polling or
use a faster server.

That's about as far (and probably further) as we can go here.  This
group is for C language questions, best send follow-ups to
comp.unix.programmer or a linux group, where questions like this are
topical.

I am sorry for that. is there any pointers for implemeting C threads
for UDP it would be helpfull for me

Ask in comp.unix.programmer. comp.programming.threads might also be
helpful, but I'd try comp.unix.programmer.

Incidentally, you seem to be having some trouble with Google Groups;
your article appeared three times.
 
N

Nick Keighley

<snip>

both Richard <surname> and Twink are trolls who try to disrupt
this news group by posting (and encouraging the posting of)
responses to non-topical questions.

Please ignore them
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,043
Latest member
CannalabsCBDReview

Latest Threads

Top