Re: Http server implementation for Windows Media Server

You'd be much better off recording the TCP-level data instead
of the raw packets. I'm assuming you are using a raw TCP
socket. Dump that idea and use a regular TCP socket instead.

To answer your question, the packets aren't ACKed because
they are all discarded as lying outside the TCP window for the
current TCP connection (due to your sequence number mismatch).

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Gur" <gur@xxxxxxxxx> wrote in message
news:%23xmNAkB2HHA.5360@xxxxxxxxxxxxxxxxxxxxxxx
In the previous post I forgot to indicate a very important fact - that
is,
the client (which is a Windows Media Player) doesn't ACKs the above
packets
which it should, since my Http server simulates for him a Windows Media
Server and sends the original packets with the slight modification of a
modified port.

Regards

Gur

"Gur" <gur@xxxxxxxxx> wrote in message
news:e3l18aA2HHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
I do it inside the Http server code. As described in the first post, the
Http server reads packets one by one from the dump, sending them to the
client after modifying tcp parameters like addresses, ports etc. In this
case everything left unchanged but the port, and the "relative sequence
number" jumps to a huge value.
Regards

Gur

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:eNrISB$1HHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
Where do you do(modify) it ?
Arkady

"Ronny" <ronny@xxxxxxxxxxx> wrote in message
news:uR9ltw%231HHA.5772@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
I think I understand a bit more following your direction...
Now to a real case that I encounter, as described in the first post
of
this
thread, modifying in the tcp packet before transmitting, just the
port
of
the client as the port is usually different than the original one,
causes
a
real time sniffer to indicate a huge "relative sequence number".
Leaving
it
without modification causes an indication of 1 - just as it was in
the
original packet. Why should the port value influence on that?
Can you explain that?

Regards

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:OSB8$$y1HHA.5884@xxxxxxxxxxxxxxxxxxxxxxx
On the tcp layer, both server's and client's tcpip stack do that
Arkady
"Gur" <gur@xxxxxxxxx> wrote in message
news:eGqSoat1HHA.484@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,
Suppose a common scenario where a standard Web Server responds to
a
GET
Http request. Does the server ever ACKs the client and when?

Thanks

Gur
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:uystfhs1HHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
That strange that no ACK appear because any data should be ACKed
Arkady

"Gur" <gur@xxxxxxxxx> wrote in message
news:ukd9yIq1HHA.1336@xxxxxxxxxxxxxxxxxxxxxxx
Hi all,

I'm trying to implement a specific Http server that listens on
port
8080
(not the standard 80). Actually it resembles a Windows Media
Server
that
also works as a HTTP server (among some other modes).
I have a dump file of prercorded transmision from an actual
Window
Media
Server and Windows Media Player, and my server implementation
should
transmit them after establishing the tcp connection with the
Player.
In reality, the connection is established but the server behaves
with
the following anomalies-
1. After the "GET" transaction by the Player, the server
transmits
an
ACK which doen't appear in the normal case.
2. The first dump packet that is being transmitted starts with
a
huge
"Realtive Sequence Number" instead of a 1.

Can someone advise please?

Regards

Gur

















.

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)
  • tcp hostcache and ip fastforward for review
    ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
    (freebsd-current)
Loading