a client-server problem

a client-server problem

Post by Luca » Fri, 23 May 2003 01:58:20



Hi all,
I want to do this:
 - receive UDP datagram from an host A;
 - delay the datagram for a time T;
 - transmit the packet to an host B.
I've to do the same thing for the datagrams sent from B to A.
My problem is that A (and B) transmit continuously, and when I delay a
packet the next packet can arrive. What type of solution can I use?
There is someone that has resolved similar problems?

I have tried to use a child process (created with fork) that, after
the reception, is interested to delay and retransmit a datagram .
After that the child is terminated. This solution is not good because
I receive approximately 380 datagram for second and then I have
problem with fork!

Thanks in advance.
   Luca

 
 
 

a client-server problem

Post by Andrew Taylo » Fri, 23 May 2003 03:04:45



> Hi all,
> I want to do this:
>  - receive UDP datagram from an host A;
>  - delay the datagram for a time T;
>  - transmit the packet to an host B.
> I've to do the same thing for the datagrams sent from B to A.
> My problem is that A (and B) transmit continuously, and when I delay a
> packet the next packet can arrive. What type of solution can I use?
> There is someone that has resolved similar problems?

A few ideas:
- use an alarm or itimer to interrupt the process when it is time to
send; see alarm(2) and setitimer(2)
- use select when reading from the socket with a timeout for when the
next packet must be sent; see select(2)
- use threads instead of processes; you should be able to do this with
only two threads: a reader and a sender

--
Andrew

 
 
 

a client-server problem

Post by Kasper Dupon » Fri, 23 May 2003 04:27:43



> Hi all,
> I want to do this:
>  - receive UDP datagram from an host A;
>  - delay the datagram for a time T;
>  - transmit the packet to an host B.
> I've to do the same thing for the datagrams sent from B to A.
> My problem is that A (and B) transmit continuously, and when I delay a
> packet the next packet can arrive. What type of solution can I use?

Implement a queue. If all packets are delayed for the same amount of
time a simple FIFO would be enough. If packets are delayed for
different amounts of time, you can have reordering and will need a
priority queue.

The algorithm then goes as follows:
1) Look at the head of the queue and compute the time to wait before
   that packet is to be sent.
2) Use select to wait for input on one or more sockets with a
   timeout. If the queue is empty just use NULL for the timeout to
   wait forever.
3) When select returns find out what happened.

If you received a packet insert it into the queue and start over
again. If you timed out send the packet from the head of the queue
and remove it from the queue, then start over again.

Quote:> I have tried to use a child process (created with fork) that, after
> the reception, is interested to delay and retransmit a datagram .
> After that the child is terminated. This solution is not good because
> I receive approximately 380 datagram for second and then I have
> problem with fork!

You could use threads, but I think select is a better solution.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

 
 
 

a client-server problem

Post by David Schwart » Fri, 23 May 2003 06:04:40



Quote:> Hi all,
> I want to do this:
>  - receive UDP datagram from an host A;
>  - delay the datagram for a time T;
>  - transmit the packet to an host B.
> I've to do the same thing for the datagrams sent from B to A.
> My problem is that A (and B) transmit continuously, and when I delay a
> packet the next packet can arrive. What type of solution can I use?
> There is someone that has resolved similar problems?

    Just use a linked list of packets with arrival timestamps. A
multithreaded approach might be easiest, but you can use a poll/select loop
type approach as well.

    Since UDP sockets are always writable, you don't have to worry about
your writes blocking. So your code could look like a big, simple loop:

    1) Compose an FD_SET include both sockets.

    2) Check if there are any packets in either queue. If not, 'select' on
the FD_SET (for readability) with a NULL timeout. Otherwise, 'select' with a
timeout equal to how long before the first packet (head of either queue)
need to be sent.

    3) Call 'select'.

    4) Note the time and see if the head packet on either queue (A-to-B or
B-to-A) is ready to send. If so, pop it off the queue and send it.

    5) If 'select' returned non-zero, check which fds are set in the read
set. Loop on 'recvmsg' on that fd until it returns EWOULDBLOCK. (Make sure
to make the sockets non-blocking!) For any received packets, stuff them in
the queue. (You already noted the time in step 4, so you can put that
information in the queue entry so you'll know when to send them.)

    6) Jump back to step 1.

    DS

 
 
 

a client-server problem

Post by Kevin Easto » Sat, 24 May 2003 00:03:57





>> Hi all,
>> I want to do this:
>>  - receive UDP datagram from an host A;
>>  - delay the datagram for a time T;
>>  - transmit the packet to an host B.
>> I've to do the same thing for the datagrams sent from B to A.
>> My problem is that A (and B) transmit continuously, and when I delay a
>> packet the next packet can arrive. What type of solution can I use?
>> There is someone that has resolved similar problems?

>    Just use a linked list of packets with arrival timestamps. A
> multithreaded approach might be easiest, but you can use a poll/select loop
> type approach as well.

>    Since UDP sockets are always writable, you don't have to worry about
> your writes blocking. So your code could look like a big, simple loop:

>    1) Compose an FD_SET include both sockets.

>    2) Check if there are any packets in either queue. If not, 'select' on
> the FD_SET (for readability) with a NULL timeout. Otherwise, 'select' with a
> timeout equal to how long before the first packet (head of either queue)
> need to be sent.

>    3) Call 'select'.

>    4) Note the time and see if the head packet on either queue (A-to-B or
> B-to-A) is ready to send. If so, pop it off the queue and send it.

That should be a while loop, in case several packets have expired at
once.

        - Kevin.

 
 
 

a client-server problem

Post by Kasper Dupon » Sat, 24 May 2003 00:31:02



> That should be a while loop, in case several packets have expired at
> once.

You might not need that. Instead you should verify that the computed
timeout for select is indeed positive. If the timeout is zero or
negative you proceed as if select had timed out imediately. I don't
know how select is going to behave if it gets a negative timeout
argument, so you'd better check that the computed value is not
negative.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

 
 
 

1. Connecting two machines:; Client only communicate with server when server continuously pings client.

Server:
Linux 2.0.29
Smc Etherez 8149
Loadable module for smc ultra v2.00
Crossover wires or smc hub and store bought cables
No Dns
No Error messages on boot up
No Error messages in logs
No problems networking locally in the server
No problem pinging the client (Linux/win)

Client:
Linux 2.0.29/Win
3com etherlink3 lan+33.6 3C562D/3C563D (pcmcia)
Pcmcia Card Services v2.9.2 or higher to version that supports the card
specifically.
No Dns
No Error messages on boot up
No Error messages in logs
No problems networking locally in the client

Problem:
Unless the Server is continuously pinging clients ip # ,
the client will comunicate with the server for a few moments, then stop.
Once I start pinging the client from the server they communicate fine.

When I run both machines in win with NetBEUI, it runs as smooth as silk.

Thanks Harley


2. Linux Zip Disk crashes Windows95

3. Sex Change - Making Server as Client and Client as Server

4. problems with quotas on solaris2.4

5. PopTop VPN Server can see Win98 client but client can't see server

6. Escom P60 Intallation woes

7. Is Linux client-server or file-server... or both?

8. AWK problem

9. Communication needed between linux server/client to windows client/server

10. Wanted: Fax Server/client for 95 clients w/ Linux server

11. Strange: Telnet client won't quit in a client-server application

12. Client-Server , problem using send(socket,...) command .