|
Home > Archive > Unix Programming > June 2005 > one question about socket listening port
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
one question about socket listening port
|
|
|
| Hello
My program is listening on one port.
When I receive a packet, I am going to process this message.
so I am using a while loop on listening.
Here is my basic structure
while(1)
{
listening on port
when Receive a packet
process the packet
}
I am wondering whether it is good, because what can I do if a new
packet is coming when I am processing my packet,
Is there any better structure for it?
Thanks a lot!
| |
| Patrick Plattes 2005-06-16, 5:52 pm |
| QQ wrote:
>
> while(1)
> {
> listening on port
> when Receive a packet
> process the packet
> }
>
> I am wondering whether it is good, because what can I do if a new
> packet is coming when I am processing my packet,
>
> Is there any better structure for it?
maybe you want to fork the process.
cu
pp
| |
| Barry Margolin 2005-06-17, 2:52 am |
| In article <1118951123.134137.171340@g44g2000cwa.googlegroups.com>,
"QQ" <junciu@yahoo.com> wrote:
> Hello
>
> My program is listening on one port.
> When I receive a packet, I am going to process this message.
> so I am using a while loop on listening.
> Here is my basic structure
>
> while(1)
> {
> listening on port
> when Receive a packet
> process the packet
> }
>
> I am wondering whether it is good, because what can I do if a new
> packet is coming when I am processing my packet,
If processing is very quick, you can keep this structure. The system
will buffer the incoming packets for you.
If not, you may want to use multiple threads. Have one thread that
listens on the socket and puts the packets it receives into a memory
queue. You can then have other threads that process the packets in the
queue.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Maxim Yegorushkin 2005-06-19, 2:48 am |
| On Fri, 17 Jun 2005 08:14:28 +0400, Barry Margolin <barmar@alum.mit.edu>
wrote:
> In article <1118951123.134137.171340@g44g2000cwa.googlegroups.com>,
> "QQ" <junciu@yahoo.com> wrote:
>
>
> If processing is very quick, you can keep this structure. The system
> will buffer the incoming packets for you.
>
> If not, you may want to use multiple threads. Have one thread that
> listens on the socket and puts the packets it receives into a memory
> queue. You can then have other threads that process the packets in the
> queue.
This is rather questionable. On a single processor machine the total time
spent in the receiving and processing threads will probably be the same as
the time spent in the original both receiving and processing thread, so by
adding threads for processing you only add overhead caused by context
switches and lock contention. If the packet rate is higher than the
processing rate in both version sooner or later you are going to start
dropping packets.
--
Maxim Yegorushkin
<firstname.lastname@gmail.com>
| |
| Barry Margolin 2005-06-19, 5:51 pm |
| In article <op.ssltk7tp3nxwlp@home>,
"Maxim Yegorushkin" <firstname.lastname@gmail.com> wrote:
> On Fri, 17 Jun 2005 08:14:28 +0400, Barry Margolin <barmar@alum.mit.edu>
> wrote:
>
>
> This is rather questionable. On a single processor machine the total time
> spent in the receiving and processing threads will probably be the same as
> the time spent in the original both receiving and processing thread, so by
If you don't use threads, you have to design your own data and control
structures for doing what the threads do automatically. You'll need a
way to do just a little bit of processing, then check for new incoming
packets, then go back to processing, and so on. This can be pretty
tricky to get right, so you're likely to be sacrificing reliability for
a small difference in performance.
There's even a good chance that your own multiplexing code will be less
performant than the kernel's context switching. This is especially
likely to be the case for the type of programmer who needs to ask for
design advice here.
> adding threads for processing you only add overhead caused by context
> switches and lock contention. If the packet rate is higher than the
> processing rate in both version sooner or later you are going to start
> dropping packets.
Only if it never lets up. Unless the incoming traffic is constant,
eventually it will slow down and you'll get caught up. My assumption is
that user memory is much larger than socket buffer memory, so you can go
much longer before needing to catch up if you buffer in user mode.
If it never slows down, no design will work -- you need to ensure that
your processor is fast enough to keep up.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Andrei Voropaev 2005-06-21, 2:50 am |
| On 2005-06-19, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <op.ssltk7tp3nxwlp@home>,
> "Maxim Yegorushkin" <firstname.lastname@gmail.com> wrote:
>
[...][vbcol=seagreen]
>
> If you don't use threads, you have to design your own data and control
> structures for doing what the threads do automatically. You'll need a
> way to do just a little bit of processing, then check for new incoming
> packets, then go back to processing, and so on. This can be pretty
> tricky to get right, so you're likely to be sacrificing reliability for
> a small difference in performance.
Well. I guess in each particular case the implementation shall differ. I
have one application, where using threads simply is a bad choice.
Because it requires a lot of synchronization between different threads,
as result the whole thing becomes damn slow and very hard to manage. On
the other hand, I've reimplemented it using poll(epoll) and it became
much faster and easier to maintain.
>
> Only if it never lets up. Unless the incoming traffic is constant,
> eventually it will slow down and you'll get caught up. My assumption is
> that user memory is much larger than socket buffer memory, so you can go
> much longer before needing to catch up if you buffer in user mode.
Maybe I'm missing something here. I always thought, that if I have to
put the data from socket into memory, then it is bad choice. I should
let TCP to slow down the incoming traffic. Well. Maybe if I definetely
knew, that after sending 10M of data the other side would stop sending
and let me process those 10M, then probably I would read all of 10M. But
in all applications I write, I can never be sure who is on the other
side, and how much data he sends. So I prefer to be on the safe side and
don't put into memory the data that I can't process. After all,
important is when the data is processed, not when the data was accepted
for processing.
--
Minds, like parachutes, function best when open
| |
| Barry Margolin 2005-06-22, 2:50 am |
| In article <3hpvteFi6b2eU1@individual.net>,
Andrei Voropaev <avorop@mail.ru> wrote:
> On 2005-06-19, Barry Margolin <barmar@alum.mit.edu> wrote:
>
> Maybe I'm missing something here. I always thought, that if I have to
> put the data from socket into memory, then it is bad choice. I should
> let TCP to slow down the incoming traffic.
I assumed the OP was using UDP, not TCP, since he talked about the
server processing packets. UDP doesn't have any automatic flow control,
so the receiver needs to get the packets out of the socket buffer as
quickly as possible. If the socket buffer fills up, packets will be
dropped.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| David Schwartz 2005-06-22, 2:50 am |
|
"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-70A146.00303922062005@comcast.dca.giganews.com...
> I assumed the OP was using UDP, not TCP, since he talked about the
> server processing packets. UDP doesn't have any automatic flow control,
> so the receiver needs to get the packets out of the socket buffer as
> quickly as possible. If the socket buffer fills up, packets will be
> dropped.
Minor nit -- we are not talking about packets but *datagrams*. If the OP
had been clear about whether he had been talking about packets, datagrams,
or segments, this misunderstanding (if there was one) wouldn't have happened
in the first place.
DS
| |
|
| I think you should then be making this as a concurrent server , either
by using fork() or pthread, depending on the type of functionality you
are implementing. Also I would suggest that have a non-blocking socket
by using select() system call which would poll each of the sockets and
process the packets if it does come on that socket.
This way you are not wasting CPU time.
| |
| Andrei Voropaev 2005-06-22, 2:50 am |
| On 2005-06-22, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <3hpvteFi6b2eU1@individual.net>,
> Andrei Voropaev <avorop@mail.ru> wrote:
>
>
> I assumed the OP was using UDP, not TCP, since he talked about the
> server processing packets. UDP doesn't have any automatic flow control,
> so the receiver needs to get the packets out of the socket buffer as
> quickly as possible. If the socket buffer fills up, packets will be
> dropped.
>
 From the type of question I assumed that the OP is new to this
subject and usually new people talk about packets even when they use TCP
But, assuming is bad thing to do. So, sorry for possible confusion.
--
Minds, like parachutes, function best when open
|
|
|
|
|